"CRV§ADER//KY" <[email protected]> writes: > Just my 2 cents: > I consider the split between set_args() and enque() a horrible C-ism - > something that should not have entered the design of PyOpenCL IMHO. > If anything, the fact that we're having this thread demonstrates that it is > not immediately obvious how that code works.
I agree and disagree with you: I agree because it's not a good API, as you say. I disagree, because first and foremost, a wrapper's job is to expose the underlying API as much as makes sense. That's why set_args and enqueue_nd_range_kernel are preserved in Python. You will notice that I try to downplay them in the docs. > In the Khronos documentation for COPY_HOST_PTR, it explicitly says: > "OpenCL implementations are allowed to cache the buffer contents pointed to > by host_ptr in device memory. This cached copy can be used when kernels are > executed on a device." > > Enphasis on "are allowed" and "can". So which instruction performs the copy > of a COPY_HOST_PTR buffer - the buffer allocation, the set_args, or the > enqueue?!? It's left at the discretion of the implementer - with > catastrophic results for the portability of your code. That's CL's design though. Contexts may span devices, and buffers may (or may not) migrate to follow kernel invocations. You can also provide hints to the implementation to migrate data on command: http://documen.tician.de/pyopencl/runtime.html#pyopencl.enqueue_migrate_mem_objects Andreas _______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
