Re: [boost] [compute] CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE

Subject: Re: [boost] [compute] CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE
From: Kyle Lutz (kyle.r.lutz_at_[hidden])
Date: 2014-12-31 01:05:06

On Tue, Dec 30, 2014 at 9:29 PM, Gruenke,Matt <mgruenke_at_[hidden]> wrote:
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Kyle Lutz
> Sent: Tuesday, December 30, 2014 23:27
> To: boost_at_[hidden] List
> Subject: Re: [boost] [compute] CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE
>
>> On Tue, Dec 30, 2014 at 6:54 PM, Gruenke,Matt wrote:
>
>>> So, will enabling out-of-order execution will break the higher level
>>> operations?  Or am I missing something?
>
>> My best guess is that any of the high-level algorithms which enqueue multiple
>> sub-operations will run into issues. This should be fixable though by storing
>> events for each sub-operation and passing them along to the next enqueue_*
>> method to maintain the proper dependency ordering.  Alternatively, and more
>> simply, we could just block off each sub-operation with a call to
>> enqueue_barrier() to force serialization.
>
> I agree that maintaining order of sub-operations should be easily fixable, in the current design.  My primary concern is maintaining order *between* higher level operations, since that might require design changes that could break API compatibility.

True, with the current algorithms API this would have to be managed
explicitly with barriers.

But looking forward more, I see out-of-order command queues being more
useful with a high-level task-graph/pipelines type API which would
allow the user to define a chain of high-level operations and
dependencies between them and then let Boost.Compute figure out how
best to split up the work and submit it for execution on a command
queue (out-of-order if available otherwise an in-order queue).

>> This is something I'd like to support cleanly, however it just hasn't been a
>> very high priority. If you're interested in writing up some test cases for
>> out-of-order command queues and fixing some of the algorithms which break
>> that would be very helpful.
>
> Having test cases seems like the least of the problems, given no confidence that they'll pass and no ready way to test them.
>
> If we can't find a backend which implements out-of-order, perhaps we could write an alternate command_queue that intentionally shuffles command order (within the specified constraints), to use in the tests.

If I recall correctly, POCL [1] supports out-of-order command queues
and could be used for testing this.

-kyle

[1] http://portablecl.org