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 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? > 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 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. > Yeah, my initial thoughts - though I can change the OpenGL update rate and still get the same effect. Thanks, Henry _______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
