Any chance, any one of you could try running the sample code I sent earlier (adapted from main pyopencl example) to see if it produces the same error on their platforms so we can eliminate whether it is a pyopencl bug on windows or a more general one?
I'm less keen on seeing alternative solutions just to see if the separation of calls actually works :) On Wed, Oct 7, 2015 at 3:03 PM, Andreas Kloeckner <[email protected]> wrote: > "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 >
_______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
