"Schock, Jonathan" <jonathan.sch...@tum.de> writes: > I found the solution to my problem. As soon as I assign a new variable name > (e.g. I copy two more images with different names) > > these copies run in parallel with kernel execution. So it has nothing to do > with the images being images but seems to be more a variable > > reference issue inside python (and probably therefore in pyopencl). I haven't > tried something equal with C bindings, but I assume that the > > same problems should not apply. > > > I have not yet tried to leverage multiple copy engines on one card, but this > should also get interesting. > > > So pseudocode for working and non-working examples: > > > > for i in range(10): > > image1 = cl.Image(...) > > cl.enqueue_copy(...,image1,...) > > cl.enqueue_nd_range_kernel(...,image1,...) > > > Does not work in parallel. > > > image1 = cl.Image(...) > > cl.enqueue_copy(...,image1,...) > > cl.enqueue_nd_range_kernel(...,image1,..) > > image2 = cl.Image(...) > > cl.enqueue_copy(...,image2,...) > > cl.enqueue_nd_range_kernel(...,image2,...) > > > DOES work in parallel. This seems to be rather a feature than a bug to me, > because it could lead to unexpected behaviour if the copy in the first > example would run during the execution of the kernel accessing the exact same > image.
Oh, you're totally right, and yes, it is intentional. I had totally forgotten about that facility (which is perhaps a testament to how well it works). Copies return a "NannyEvent" (that's literally what it's called) that (a) keeps the buffer alive until the end of the transfer and (b) waits for completion when it's garbage collected. Andreas _______________________________________________ PyOpenCL mailing list PyOpenCL@tiker.net https://lists.tiker.net/listinfo/pyopencl
