unified memory buffer shared with opencl, kaputt.

OpenGL Development
#1

i asked about it on LWJGL forums but maybe you guys know …

just cannot figure out what exactly is going on … here’s how you can probably recreate the issue :

= all good

now with openCL :

…

  • upload some mesh
  • share with opencl (clCreateFromGLBuffer)
  • modify buffer with compute shader
  • dont use opencl yet at all
  • draw it

= not good, it is drawing the mesh fine but not the modification by compute shader.

now, the same applies to opencl as you’d guess.

…

  • share with opencl
  • modify buffer with opencl
  • draw

= same results, modification not visible.

using the “usual” way, non-resident with a VAO and glVertexPointer etc works just fine. with compute shader and opencl even at the same time.

what i do not understand is, since the resident buffer is readable/writeable fine from a compute shader, in what way is clCreateFromGLBuffer affecting or changing the buffer and how can we stop opencl from doing that ?

i tried releasing the cl-buffer just after clCreate, nothing. making it non-resident and resident again, nothing. for the compute shader it is kaputt until i destroy recreate the buffer. plain uploading and drawing is working fine all the time tho’ >:( = i guess the buffers gpu-address pointer is not changed, gpu would crash at least.

:persecutioncomplex:

#2

I might be misunderstanding but make sure you use clFinish and glFinish when doing opencl-opengl interop also keep in mind that you have to bind the buffer to the openCL context when you are doing openCL stuff then unbind it so that GL gets it back (clReleaseMemObject call). Also, a compute shader is part of the OpenGL pipeline, so you should not use any openCL for it. In fact, one big reason for it is to avoid the big overhead between openCL and openGL interop.

#3

o/

yes. i use at least glFlush/glFinish. glFinish is recomended : http://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/clEnqueueAcquireGLObjects.html

after that i put clEnqueueAcquireGLObjects into the inorder-cl-que.
after finishing moving vertices, clEnqueueReleaseGLObjects.

all good, renders fine with non-resident buffers.

actually when looking on the performance, CS and CL perform about the same speed. without any flushing/finishing CL performs even better. tho’ that is dangerous! looks like my driver is able to handle that somehow … without visible glitches :). no but that’s silly.

i dont mind the overhead (it’s not that much anyway), just comparing the two system to see which one goes better with stuff that is actually another story :slight_smile: