Yes, this is plausible, but I'm a little doubtful - it seems rather too
repeatable a problem (the same lines seem to get corrupted each time,
and not in a spurious way, but in a drop-out way. That said, I'll keep
it in mind during my investigations!
I'm inclined at the moment to think it could be the beignet drivers.
I've found in the past they don't always behave quite right, and it
could easily be those.
On 25/11/15 18:54, CRV§ADER//KY wrote:
I suggest you check your opencl code for buffer
overflows. Not sure how
memory segmentation works in VRAM but I would expect two threads of the
same process to be able to freely write to each other's memory, just
like in regular RAM.
Try replacing your opencl code with something trivial (that simply keeps
the gpu busy) and see if the problem disappears.
On 25 Nov 2015 5:28 pm, "Karl Czajkowski" <karlcz(a)isi.edu
On Nov 25, Henry Gomersall modulated:
The OpenGL context is created independently of
the OpenCL context and
exists in a different thread. I'm currently making no attempt to share
data between OpenGL and OpenCL - all the data passes via the CPU.
How is this sharing via CPU done? Are you copying data into opengl
vertex buffers or textures via opengl API calls? Are these calls done
in the opengl thread at the right point in the rendering loop?
At the very least, you need to do something to synchronize your reads
of results from the opencl thread and your writes to the opengl
thread. I would expect you'd copy opencl results into Python during
the opencl thread (between kernel runs) and stick them in a
synchronized Python structure to then pull them out and send to opengl
from the opengl thread.
I'm finding that I'm getting substantial
artifacts in the OpenGL
rendering. Specifically, I get a heavy flickering of the rendering
looks like e.g. certain line segments are not
being drawn (it's a
line drawing program) for some frame.
Is the renderer using line vertices copied over from opencl results?
Do the missing lines make sense as rendering a partially copied array?
Also, are you using double-buffering in opengl so that only completely
rendered frames will be swapped to the display? Otherwise, you could
also see parts of the scene drawn or missing depending on when they
happen relative to the vertical blanking period and buffer clearing.
Curiously, it doesn't break _every_ run.
About 1 run in 10 works
perfectly, with no visual problems at all. I wonder if there is some
race condition causing a (setup?) problem.
This could be dumb luck that the workers get phase-locked and
synchronized by accident.
PyOpenCL mailing list