clCreateFromGLRenderbuffer !!! Error # -38

Did anyone use color/depth Renderbuffer as a cl_mem arg in the kernel ?

[codebox]void createFBO(GLuint &fbo, GLuint &renderBuffer, cl_mem &cl_renderBuffer)


//create and bind FBO

glGenFramebuffersEXT(1, &fbo);

glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);

//create DEPTH24 render buffer

glGenRenderbuffersEXT(1, &renderBuffer);

glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, renderBuffer);


//attach it as depth attachment to FBO




GLenum fboStatus = glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT);



   fprintf(stderr, "FBO Error!\n");


cl_renderBuffer = clCreateFromGLRenderbuffer(cxGPUContext, CL_MEM_READ_ONLY, renderBuffer, &ciErrNum);

shrCheckErrorEX(ciErrNum, CL_SUCCESS, pCleanUp);


I have an error message at line cl_renderBuffer = clCreateFromGLRenderbuffer (…);

Did you create your CL context correctly, passing in your GL context and DC to the creation function as properties ? (or equiv on non-windows platforms).

sure, did you achieve something on that ?

Yup, using driver version 95.39 and Beta SDK 3.0, on Windows XP, I was able to use GL interoperability fine (I’ve tested it on 6800, 8800, and GTX285). Though I only used shared VBOs and Images, not render buffers.

Additionally I always created the CL object immediately after the GL object, before I actually use it in a kernel or a GL operation. I noticed once an texture/image had been used by GL I could not access the bits via the CL C API, only via the GL glGetTexImage API.

Another gotcha I noticed is the event argument to the Aquire/Release functions is never filled in by them.

those are fine, but not FBO

100% true

that’s why we have an API

more precisely, please

Well if it is shared, you’d expect either API to work.

I don’t think its anything to do with your problem. But if you pass an event pointer into clEnqueueAcquireGLObjects or clEnqueueReleaseGLObjects then it is ignored (and if you try release or wait on the value you passed in your get an error, as it will be uninitialized).


the error appears even before in cl_mem clRBO=clCreateFromGLRenderbuffer() initialization, so I think it is under development

Though is CL_MEM_READ_ONLY the access right flag ? Even if your CL kernel only reads from it, the GL code is writing to it (which presumably amounts to the same thing under the hood), shouldn’t t be read+write ?


[codebox] // create buffer object

glGenBuffers(1, pbo);

glBindBuffer(GL_ARRAY_BUFFER, *pbo);

glBufferData(GL_ARRAY_BUFFER, size_tex_data, NULL, GL_DYNAMIC_DRAW);

cl_pbo = clCreateFromGLBuffer(cxGPUContext, CL_MEM_READ_ONLY, pbo, &ciErr);

//the same for VBO, as for all bufferObjects


does not matter - whenever GL writes to it or not, you initialize it as read_only to cl_mem variable, if you are going to read it in kernel

so once again, afaik, this feature is still under development

Actuallly look at the spec:

There are no depth-buffer formats in the table.

yes, there are, because it is GL_FLOAT/CL_FLOAT for depthBuffer

specs are ok, but its implementation is still not finished by vendors, it is normal

It works find for me if I replace GL_DEPTH_COMPONENT24 with GL_RGBA8 and hook it up to the color attachment point.

were you able to pass it as an arg to your kernel ?