Hello,

I'm very sorry that have posted about a wrong problem. Really the bug was
in Python code that writes down results in a separate process. Still, big
thanks for advice. I'd only like to note that in the code pointers are
updated on each kernel call, so it shouldn't probably be an issue.

Regards,
Alex

On Tue, Nov 6, 2012 at 9:47 PM, Andreas Kloeckner
<[email protected]>wrote:

> Hi Alex,
>
> Alexander Kiselyov <[email protected]> writes:
> > I have run across a quite strange problem with getting data from OpenCL
> > device. Currently it is Intel CPU, but the problem seems to persist also
> on
> > nVidia GPU.
> >
> > The thing is that figures in OpenCL code which are written to output
> arrays
> > differ significantly from ones received on host-side. There is a graph
> > illustrating the situation: http://ghost.net/41372977/image.png (black
> line
> > corresponds precisely to theoretical one). I thought about it being a
> > synchronization issue in device code, but I have put barriers in almost
> all
> > suspicious places.
>
> Your image link goes to some Halloween-themed domain squatter page for me.
>
> > Here is Python code which fills the buffers (maybe the problem is in
> wrong
> > buffer parameters):
> >
> https://github.com/yl3dy/Plasma-Particles/blob/master/model/opencl.py#L33
> > And here is OpenCL code:
> > https://github.com/yl3dy/Plasma-Particles/blob/master/cl/main.cl#L6
> > Basically, it accepts 4 main arrays (2 for electrons, 2 for ions), and
> > device performs 2 iterations on itself, swapping pairs of arrays. After
> > that the control is returned to host, and it writes 1 electron and 1 ion
> > arrays to disk.
>
> Someone on this list would be more likely to be able to help you if
> could provide a reduced test case of where you think data is being
> transferred wrongly.
>
> One thing I noticed is that you're storing global pointers in global
> memory. By the letter of the CL standard, that invokes undefined
> behavior, as pointers to the same buffer are allowed to change from one
> invocation to the next, i.e. the CL implementation is free to move
> around buffers in device memory. That said, it's likely fine for most
> implementations.
>
> Next, note that you can't transfer pointers from the device to the host
> and expect them to still be valid--this might be part of the problem, or
> it might not.
>
> Hope that helps at least a bit.
>
> Andreas
>
_______________________________________________
PyOpenCL mailing list
[email protected]
http://lists.tiker.net/listinfo/pyopencl

Reply via email to