On Tue, Dec 30, 2014 at 9:29 PM, Gruenke,Matt <mgruenke@tycoint.com> wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Kyle Lutz Sent: Tuesday, December 30, 2014 23:27 To: boost@lists.boost.org 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