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. Thanks, Henry 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" <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > http://lists.tiker.net/listinfo/pyopencl > _______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
