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" &lt;karlcz(a)isi.edu <mailto:karlcz@isi.edu>> wrote: On Nov 25, Henry Gomersall modulated: 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. - it simple 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. This could be dumb luck that the workers get phase-locked and synchronized by accident. Karl _______________________________________________ PyOpenCL mailing list PyOpenCL(a)tiker.net <mailto:PyOpenCL@tiker.net> http://lists.tiker.net/listinfo/pyopencl