|
Boost : |
Subject: Re: [boost] [compute] CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE
From: Gruenke,Matt (mgruenke_at_[hidden])
Date: 2014-12-31 00:29:04
-----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.
> 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.
Matt
________________________________
This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk