Files
test/intern/memutil/MEM_CacheLimiterC-Api.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

145 lines
3.5 KiB
C
Raw Permalink Normal View History

/* SPDX-FileCopyrightText: 2006-2023 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
/** \file
* \ingroup intern_memutil
2011-02-25 11:47:18 +00:00
*/
#ifndef __MEM_CACHELIMITERC_API_H__
#define __MEM_CACHELIMITERC_API_H__
#include <cstddef>
BLI: Replace some macros with inlined functions for C++ Covers the macro ARRAY_SIZE() and STRNCPY. The problem this change is aimed to solve it to provide cross-platform compiler-independent safe way pf ensuring that the functions are used correctly. The type safety was only ensured for GCC and only for C. The C++ language and Clang compiler would not have detected issues of passing bare pointer to neither of those macros. Now the STRNCPY() will only accept a bounded array as the destination argument, on any compiler. The ARRAY_SIZE as well, but there are a bit more complications to it in terms of transparency of the change. In one place the ARRAY_SIZE was used on float3 type. This worked in the old code because the type implements subscript operator, and the type consists of 3 floats. One would argue this is somewhat hidden/implicit behavior, which better be avoided. So an in-lined value of 3 is used now there. Another place is the ARRAY_SIZE used to define a bounded array of the size which matches bounded array which is a member of a struct. While the ARRAY_SIZE provides proper size in this case, the compiler does not believe that the value is known at compile time and errors out with a message that construction of variable-size arrays is not supported. Solved by converting the field to std::array<> and adding dedicated utility to get size of std::array at compile time. There might be a better way of achieving the same result, or maybe the approach is fine and just need to find a better place for such utility. Surely, more macro from the BLI_string.h can be covered with the C++ inlined functions, but need to start somewhere. There are also quite some changes to ensure the C linkage is not enforced by code which includes the headers. Pull Request: https://projects.blender.org/blender/blender/pulls/108041
2023-05-23 09:21:45 +02:00
#ifdef __cplusplus
extern "C" {
#endif
struct MEM_CacheLimiter_s;
struct MEM_CacheLimiterHandle_s;
using MEM_CacheLimiterC = struct MEM_CacheLimiter_s;
using MEM_CacheLimiterHandleC = struct MEM_CacheLimiterHandle_s;
/* function used to remove data from memory */
using MEM_CacheLimiter_Destruct_Func = void (*)(void *);
/* function used to measure stored data element size */
using MEM_CacheLimiter_DataSize_Func = size_t (*)(void *);
/* function used to measure priority of item when freeing memory */
using MEM_CacheLimiter_ItemPriority_Func = int (*)(void *, int);
/* function to check whether item could be destroyed */
using MEM_CacheLimiter_ItemDestroyable_Func = bool (*)(void *);
#ifndef __MEM_CACHELIMITER_H__
void MEM_CacheLimiter_set_maximum(size_t m);
Prefetching for movie clips This commit basically implements frames prefetching for movie clip datablock. Number of frames to be prefetched is controlled in User Preferences, System tab, Prefetch Frames option. Currently prefetching is destructive-less for movie cache, meaning mo frames will be removed from the cache when while prefetching. This is because it's half of simplier to implement, but it also makes sense from tracking point of view -- we could want to playback in both directions and removing frames from behind time cursor is not always a good idea. Anyway, smarter prefetching strategy could be developed later. Some implementation notes: - Added MEM_CacheLimiter_get_memory_in_use function to get memory usage of specified memory limiter. - Fixed prototype of MEM_CacheLimiter_get_maximum which was simply wrong (used wrong data type for output). - Added some utility functions to movie clip and movie cache for direct cache interaction and obtaining cache statistics. - Prefetching is implemented using general jobs system. which is invoking from clip draw function. - Prefetcing will stop as soon other job or playback starts. This is done from performance point of view. Jobs will likely require lots of CPU power and better to provide whole CPU to it. Playback is a bit more complicated case. For jpeg sequence playback prefetching while paying back is nice. But trying to prefetch heavy exr images and doing color space conversion slows down both playback and prefetching. TODO: - Think of better policy of dealing with already cached frames (like when cached frames from other clips prevents frames from current clip to be prefetched) - Currently a bit funky redraw notification happens from prefetch job. Perhaps own ND_ is better to have here. - Hiding clip while prefetch is active in theory shall stop prefetching job. - Having multiple clips opened on file load will prefetch frames for only one of them.
2013-03-20 17:03:20 +00:00
size_t MEM_CacheLimiter_get_maximum(void);
void MEM_CacheLimiter_set_disabled(bool disabled);
bool MEM_CacheLimiter_is_disabled(void);
#endif /* __MEM_CACHELIMITER_H__ */
/**
* Create new MEM_CacheLimiter object
* managed objects are destructed with the data_destructor
*
2020-05-09 17:29:27 +10:00
* \param data_destructor: TODO.
* \return A new #MEM_CacheLimter object.
*/
MEM_CacheLimiterC *new_MEM_CacheLimiter(MEM_CacheLimiter_Destruct_Func data_destructor,
MEM_CacheLimiter_DataSize_Func data_size);
/**
* Delete MEM_CacheLimiter
*
* Frees the memory of the CacheLimiter but does not touch managed objects!
*
2020-05-09 17:29:27 +10:00
* \param This: "This" pointer.
*/
void delete_MEM_CacheLimiter(MEM_CacheLimiterC *This);
/**
* Manage object
*
2023-03-29 14:16:26 +11:00
* \param This: "This" pointer, data object to manage.
* \return The handle to reference/unreference & touch the managed object.
*/
2012-10-28 15:23:16 +00:00
MEM_CacheLimiterHandleC *MEM_CacheLimiter_insert(MEM_CacheLimiterC *This, void *data);
/**
* Free objects until memory constraints are satisfied
*
2020-05-09 17:29:27 +10:00
* \param This: "This" pointer.
*/
void MEM_CacheLimiter_enforce_limits(MEM_CacheLimiterC *This);
/**
* Unmanage object previously inserted object.
* Does _not_ delete managed object!
*
2020-05-09 17:29:27 +10:00
* \param handle: of object.
*/
void MEM_CacheLimiter_unmanage(MEM_CacheLimiterHandleC *handle);
/**
* Raise priority of object (put it at the tail of the deletion chain)
*
2020-05-09 17:29:27 +10:00
* \param handle: of object.
*/
void MEM_CacheLimiter_touch(MEM_CacheLimiterHandleC *handle);
/**
* Increment reference counter. Objects with reference counter != 0 are _not_
* deleted.
*
2020-05-09 17:29:27 +10:00
* \param handle: of object.
*/
void MEM_CacheLimiter_ref(MEM_CacheLimiterHandleC *handle);
/**
* Decrement reference counter. Objects with reference counter != 0 are _not_
* deleted.
*
2020-05-09 17:29:27 +10:00
* \param handle: of object.
*/
void MEM_CacheLimiter_unref(MEM_CacheLimiterHandleC *handle);
/**
* Get reference counter.
*
2020-05-09 17:29:27 +10:00
* \param handle: of object.
*/
int MEM_CacheLimiter_get_refcount(MEM_CacheLimiterHandleC *handle);
/**
* Get pointer to managed object
*
2020-05-09 17:29:27 +10:00
* \param handle: of object.
*/
2012-10-28 15:23:16 +00:00
void *MEM_CacheLimiter_get(MEM_CacheLimiterHandleC *handle);
void MEM_CacheLimiter_ItemPriority_Func_set(MEM_CacheLimiterC *This,
MEM_CacheLimiter_ItemPriority_Func item_priority_func);
void MEM_CacheLimiter_ItemDestroyable_Func_set(
MEM_CacheLimiterC *This, MEM_CacheLimiter_ItemDestroyable_Func item_destroyable_func);
Prefetching for movie clips This commit basically implements frames prefetching for movie clip datablock. Number of frames to be prefetched is controlled in User Preferences, System tab, Prefetch Frames option. Currently prefetching is destructive-less for movie cache, meaning mo frames will be removed from the cache when while prefetching. This is because it's half of simplier to implement, but it also makes sense from tracking point of view -- we could want to playback in both directions and removing frames from behind time cursor is not always a good idea. Anyway, smarter prefetching strategy could be developed later. Some implementation notes: - Added MEM_CacheLimiter_get_memory_in_use function to get memory usage of specified memory limiter. - Fixed prototype of MEM_CacheLimiter_get_maximum which was simply wrong (used wrong data type for output). - Added some utility functions to movie clip and movie cache for direct cache interaction and obtaining cache statistics. - Prefetching is implemented using general jobs system. which is invoking from clip draw function. - Prefetcing will stop as soon other job or playback starts. This is done from performance point of view. Jobs will likely require lots of CPU power and better to provide whole CPU to it. Playback is a bit more complicated case. For jpeg sequence playback prefetching while paying back is nice. But trying to prefetch heavy exr images and doing color space conversion slows down both playback and prefetching. TODO: - Think of better policy of dealing with already cached frames (like when cached frames from other clips prevents frames from current clip to be prefetched) - Currently a bit funky redraw notification happens from prefetch job. Perhaps own ND_ is better to have here. - Hiding clip while prefetch is active in theory shall stop prefetching job. - Having multiple clips opened on file load will prefetch frames for only one of them.
2013-03-20 17:03:20 +00:00
size_t MEM_CacheLimiter_get_memory_in_use(MEM_CacheLimiterC *This);
#ifdef __cplusplus
}
#endif
#endif // __MEM_CACHELIMITERC_API_H__