clEnqueueReadBuffer and a still running kernel

[Z98]

I’m wondering if I try to call clEnqueueReadBuffer with nonblocking on a kernel that is still running, will the read buffer command not go until the kernel is finished? I hope this is the case, but the OpenCL spec doesn’t really state this explicitly. I ask because I’m getting weird results from my kernel and I almost wonder whether it’s due to an incomplete copy.

[_Big_Mac]

It’s not guaranteed to wait for kernel completion and likely won’t. You need to explicitly synchronize or pass an event object around.

[Martin_Nilsson]

It this synchronization required even with in-order queues?

[_Big_Mac]

Hm, the specs say

If the CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE property of a command-queue is

not set, the commands enqueued to a command-queue execute in order. For example, if an

application calls clEnqueueNDRangeKernel to execute kernel A followed by a

clEnqueueNDRangeKernel to execute kernel B, the application can assume that kernel A

finishes first and then kernel B is executed. If the memory objects output by kernel A are inputs

to kernel B then kernel B will see the correct data in memory objects produced by execution of

kernel A.

Which means with in-order queues you shouldn’t need to manually sync.

Looking into the sources from SDK, they don’t manually sync clEnqueueReadBuffer after a kernel launch so with in-order execution there should be no need to.

Z98, are you using a single, in-order command queue?

[Z98]

I believe so, since I never set that flag, nor was I aware of its existence. I’ve only made it through about maybe 15% of the entire spec in detail and my searches through the PDF never got me to anything like that. Though fortunately me and the rest of my team have come up with a different theory for why the results are borked.