Skip to content

va: allocators fixes & improvements

    va: allocator: add a memory pool object helper
    
    Since both allocators use a memory pool, with its mutex and cond, this patch
    refactors it into a single internal object, implementing a generic GstMemory
    pool.
    va: pool, allocator: honor GST_BUFFER_POOL_ACQUIRE_FLAG_DONTWAIT
    
    In order to honor GST_BUFFER_POOL_ACQUIRE_FLAG_DONTWAIT in VA pool, allocators'
    wait_for_memory() has to be decoupled from their prepare_buffer() so it could be
    called in pools' acquire_buffer() if the flag is not set.
    
    wait_for_memory() functions are blocking so the received memories are assigned
    to the fist requested buffer, if multithreaded calls. For this a new mutex were
    added.
    va: allocator: broadcast when flushing
    
    This patch handles when the bufferpool request a new buffer while
    flushing.
    
    Also fixes the usage of g_cond_wait(), which demands to be used
    inside a loop to avoid spurious wakeups.
    va: allocator: free allocator when a mem is held
    
    An application, using for example appsink, can hold buffers from any
    va allocator after setting the pipeline to NULL. We need to destroy
    the allocator when that memory is unrefed.
    
    This patch juggles a bit with the allocator reference count in
    memories in order to achieve this:
    
    1. When memory is created no alloc ref is modified
    2. When memory is released, alloc ref is decreased
    3. When memory is reassiged to a buffer, alloc ref is increased
    4. When memory is flushed, alloc ref is increased becase it is going
       to be decreased in gst_memory_unref()
    
    Also this patch moves the deallocation of member variables to
    finalize() rather than dispose()
    va: allocator: dmabuf: initialize cond
Edited by Víctor Manuel Jáquez Leal

Merge request reports