25 Nov
2015
25 Nov
'15
4:19 p.m.
In my software I have computation being done with pyOpenCL and the
rendering being done with pyOpenGL and GLSL.
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.
The OpenCL code is run very much more often than the OpenGL rendering
code (say 500 times per second versus 50 times per second for rendering).
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.
Am I missing something about using OpenCL and OpenGL from multiple
threads? Do I need to explicitly sync the objects in some way?
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.
Thanks,
Henry
25 Nov
25 Nov
5:24 p.m.
Am 25.11.2015 um 17:19 schrieb Henry Gomersall
<heng(a)cantab.net>et>:
In my software I have computation being done with pyOpenCL and the
rendering being done with pyOpenGL and GLSL.
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.
The OpenCL code is run very much more often than the OpenGL rendering
code (say 500 times per second versus 50 times per second for rendering).
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.
Am I missing something about using OpenCL and OpenGL from multiple
threads? Do I need to explicitly sync the objects in some way?
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.
Dear Henry,
I have an application with a similar specs as you described, with PyQt4, pyOpenGL and
pyopencl, but without issues. Even sucessfully tried sharing between OpenCL and OpenGL.
One thing I learned about Qt, do all the OpenGL rendering in the main thread, and then
ideally do everything within the paintGL() method of QGLWidgdet, or call makeCurrent
(method of QGLWidget) to switch the OpenGL context. Having another threads keeping the GPU
busy with OpenCL did not interfere with rendering.
Gregor
Thanks,
Henry
_______________________________________________
PyOpenCL mailing list
PyOpenCL(a)tiker.net
http://lists.tiker.net/listinfo/pyopencl
6:29 p.m.
New subject: OpenGL corruption with OpenCL and OpenGL in separate threads
On 25/11/15 17:24, Gregor Thalhammer wrote:
Yes, this is what I'm doing. hmmm...
Thanks,
Henry
> Am
25.11.2015 um 17:19 schrieb Henry Gomersall <heng(a)cantab.net>et>:
>
> In my software I have computation being done with pyOpenCL and the
> rendering being done with pyOpenGL and GLSL.
>
> 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.
>
> The OpenCL code is run very much more often than the OpenGL rendering
> code (say 500 times per second versus 50 times per second for rendering).
>
> 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.
>
> Am I missing something about using OpenCL and OpenGL from multiple
> threads? Do I need to explicitly sync the objects in some way?
>
> 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.
Dear Henry,
I have an application with a similar specs as you described, with PyQt4, pyOpenGL and
pyopencl, but without issues. Even sucessfully tried sharing between OpenCL and OpenGL.
One thing I learned about Qt, do all the OpenGL rendering in the main thread, and then
ideally do everything within the paintGL() method of QGLWidgdet, or call makeCurrent
(method of QGLWidget) to switch the OpenGL context. Having another threads keeping the GPU
busy with OpenCL did not interfere with rendering. 
5:28 p.m.
New subject: OpenGL corruption with OpenCL and OpenGL in separate threads
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 - 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?
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.
Karl
6:28 p.m.
New subject: OpenGL corruption with OpenCL and OpenGL in separate threads
On 25/11/15 17:28, Karl Czajkowski wrote:
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.
Yeah, my initial thoughts - though I can change the OpenGL update rate
and still get the same effect.
Thanks,
Henry
On Nov 25, Henry Gomersall modulated:
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).
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.
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
rendering thread.
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?
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.
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
causing problems?
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.
6:54 p.m.
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> 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?
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 - 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?
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.
Karl
_______________________________________________
PyOpenCL mailing list
PyOpenCL(a)tiker.net
http://lists.tiker.net/listinfo/pyopencl
1886
days inactive
1886
days old
5 comments
4 participants
participants (4)
-
CRV§ADER//KY -
Gregor Thalhammer -
Henry Gomersall -
Karl Czajkowski