On 25/11/15 17:28, Karl Czajkowski wrote:
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?
Yes, the VBO is populated using OpenGL calls at what I _think_ is the
correct location - during the requisite draw command (it uses Qt through
PySide, so in the paintGL method override).
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.
Exactly, the python code reads in the OpenCL result and copies to a
numpy array (using .get() on a clArray) and then passes it to the
It all works just great when the CPU is doing the data production, so
I've no concerns about basic thread synchronization.
I'm finding that I'm getting substantial
artifacts in the OpenGL
rendering. Specifically, I get a heavy flickering of the rendering - it
looks like e.g. certain line segments are not being drawn (it's a simple
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?
Yes, but via arrays in main memory. It looks to me like it's simply
missing line segments from the VBO - like the fragment shader is not
being called in every case or something.
Also, are you using double-buffering in opengl so that
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.
No, not currently. But I've never seen such a problem when producing
data from CPU - though plausibly the extra work the GPU is doing is
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.
Yeah, my initial thoughts - though I can change the OpenGL update rate
and still get the same effect.