einpoklum
einpoklum

Reputation: 132128

Why do OpenCL enqueue API functions take event lists, when we can enqueue a barrier?

OpenCL command queues' enqueue API functions typically take a sequence of dependency events. For example:

cl_int clEnqueueCopyBuffer(
    cl_command_queue command_queue,
    cl_mem src_buffer,
    cl_mem dst_buffer,
    size_t src_offset,
    size_t dst_offset,
    size_t size,
    cl_uint num_events_in_wait_list,  // <--- Note this
    const cl_event* event_wait_list,  // <--- Note this
    cl_event* event);

(the last parameter is an output event - that of the enqueued barrier being reached).

Well, the thing is, a command queue can also have a barrier enqueued, depending on a bunch of events:

cl_int clEnqueueBarrierWithWaitList(
    cl_command_queue command_queue,
    cl_uint num_events_in_wait_list,
    const cl_event* event_wait_list,
    cl_event* event);

So, if we want to perform operation, like the buffer copy, and have it depend on events events, we can just do:

clEnqueueBarrierWithWaitList(my_queue, n, events, nullptr);
clEnqueueCopyBuffer(
    src_buffer, dst_buffer, src_offset, dst_offset, size,
    0, nullptr, nullptr);

i.e. the event_wait_list specification seems completely redundant - a two-actions-in-one-API-call type thing. And we have this same pair of arguments for most/all other enqueue API functions.

My question is: Why? What is the use in having this second avenue for specifying dependencies, making the code more complex and repetitive?

Upvotes: 1

Views: 12

Answers (0)

Related Questions