clCreateFromGLRenderbuffer !!! Error # -38

[kreon]

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);

glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_DEPTH_COMPONENT24, uiNI, uiNJ);

//attach it as depth attachment to FBO

glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_RENDERBUFFER_EXT, renderBuffer);

glDrawBuffer(GL_NONE);

glReadBuffer(GL_NONE);

GLenum fboStatus = glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT);

if (fboStatus != GL_FRAMEBUFFER_COMPLETE_EXT)

{

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

}

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

shrCheckErrorEX(ciErrNum, CL_SUCCESS, pCleanUp);

}[/codebox]

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

[griffin2000]

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).

[kreon]

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 ?

[griffin2000]

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.

[kreon]

Though I only used shared VBOs and Images, not render buffers.

those are fine, but not FBO

Additionally I always created the CL object immediately after the GL object, before I actually use it in a kernel or a GL operation.

100% true

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.

that’s why we have an API

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

more precisely, please

[griffin2000]

that’s why we have an API

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

more precisely, please

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).

[kreon]

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

right

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

[griffin2000]

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 ?

[kreon]

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 ?

no,

[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

[/codebox]

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

[griffin2000]

Actuallly look at the spec:

The table below describes the list of GL renderbuffer internal formats and the corresponding CL image formats. If a GL renderbuffer object with an internal format from the table below is successfully created by OpenGL, then there is guaranteed to be a mapping to one of the corresponding CL image format(s) in that table. Renderbuffer objects created with other OpenGL internal formats may (but are not guaranteed to) have a mapping to a CL image format; if such mappings exist, they are guaranteed to preserve all color components, data types, and at least the number of bits/component actually allocated by OpenGL for that format.

There are no depth-buffer formats in the table.

[kreon]

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

[griffin2000]

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.

[kreon]

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 ?