On 28/06/17 15:03, wm4 wrote:
> On Wed, 28 Jun 2017 13:36:30 +0100
> Mark Thompson <s...@jkqxz.net> wrote:
>
>> On 28/06/17 12:03, wm4 wrote:
>>> On Tue, 27 Jun 2017 22:50:44 +0100
>>> Mark Thompson <s...@jkqxz.net> wrote:
>>>
>>>> ---
>>>> configure | 5 +-
>>>> doc/APIchanges | 4 +
>>>> libavutil/Makefile | 2 +
>>>> libavutil/hwcontext.c | 4 +
>>>> libavutil/hwcontext.h | 1 +
>>>> libavutil/hwcontext_internal.h | 1 +
>>>> libavutil/hwcontext_opencl.c | 1303
>>>> ++++++++++++++++++++++++++++++++++++++++
>>>> libavutil/hwcontext_opencl.h | 96 +++
>>>> libavutil/version.h | 4 +-
>>>> 9 files changed, 1417 insertions(+), 3 deletions(-)
>>>> create mode 100644 libavutil/hwcontext_opencl.c
>>>> create mode 100644 libavutil/hwcontext_opencl.h
>>>> ...
>>>> +/**
>>>> + * OpenCL frame descriptor for pool allocation.
>>>> + *
>>>> + * In user-allocated pools, AVHWFramesContext.pool must return
>>>> AVBufferRefs
>>>> + * with the data pointer pointing at an object of this type describing the
>>>> + * planes of the frame.
>>>> + */
>>>> +typedef struct AVOpenCLFrameDescriptor {
>>>> + /**
>>>> + * Number of planes in the frame.
>>>> + */
>>>> + int nb_planes;
>>>> + /**
>>>> + * OpenCL image2d objects for each plane of the frame.
>>>> + */
>>>> + cl_mem planes[AV_NUM_DATA_POINTERS];
>>>> +} AVOpenCLFrameDescriptor;
>>>
>>> Not sure if this should have more metadata about the formats?
>>
>> I'm not sure what other metadata you want here? This structure is used as
>> the buffer reference, and also then also to carry the objects for some
>> mapping cases where that is useful. It doesn't actually end up in the frame
>> itself.
>
> Well, the semantics of those are bound to sw_format, but in the end
> it's all a bit obscure, undocumented, and hidden in the source code.
>
>>>> +
>>>> +/**
>>>> + * OpenCL device details.
>>>> + *
>>>> + * Allocated as AVHWDeviceContext.hwctx
>>>> + */
>>>> +typedef struct AVOpenCLDeviceContext {
>>>> + /**
>>>> + * The primary device ID of the device. If multiple OpenCL devices
>>>> + * are associated with the context then this is the one which will
>>>> + * be used for all operations internal to Libav.
>>>> + */
>>>> + cl_device_id device_id;
>>>> + /**
>>>> + * The OpenCL context which will contain all operations and frames on
>>>> + * this device.
>>>> + */
>>>> + cl_context context;
>>>> + /**
>>>> + * The default command queue for this device, which will be used by
>>>> all
>>>> + * frames contexts which do not have their own command queue. If not
>>>> + * intialised by the user, a default queue will be created on the
>>>> + * primary device.
>>>> + */
>>>> + cl_command_queue command_queue;
>>>> +} AVOpenCLDeviceContext;
>>>
>>> Is the default queue also set on the public struct if created by Libav?
>>
>> Not currently - it stays internal so that it is clear where all of the
>> references to it are.
>>
>> It could be put here with suitable documentation if you want?
>
> Sure. Should the command queue be accessible to API users? If not, why
> can the API user _set_ it?
The API user can set it in order to be able to enforce operation ordering in
the way they want. Since the API isn't exposing any event interface, you need
some way to be sure that dependent events (such as writing the contents of the
frame you are about to download) have completed. Controlling the command queue
the transfer is executed on allows you to set such dependencies externally,
with barriers on a common queue or by enqueuing a wait for events on another
queue.
You can also do everything synchronously (always call clFinish() to make sure
kernels have finished running) - then none of that is needed and you don't have
to touch any of this.
(I have thoughts of allowing the opposite case as well, so that transfer
operations don't need to wait for completion internally. It would require
adding a new flag something like AV_HWFRAME_TRANSFER_ASYNCHRONOUS, though, so I
haven't yet pursued it.)
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
