Possible bug in cl_khr_gl_sharing

Possible bug in cl_khr_gl_sharing

I discovered possible bug when using your GL sharing extension. I share three renderbuffers as read only and one texture as write only between CL and GL.

When I read in kernel from renderbuffer or write to the texture, it does not work (texture data is empty on GPU after I write to it in kernel which runs on CPU). So it seems no data is transferred between GL and CL.

I tried to debug the application with gDEBugger, and it shows that a GL error happens in intelocl.dll.
It also shows the command that causes the error:
glReadPixels(0 , 0 , 512 , 512 , GL_RGBA_INTEGER , 0 , 0x11970080)
The error is GL_INVALID_ENUM and I guess because of the 6th argument. Since my CL kernel runs on CPU, the CL implementation I think has to copy to or read from GPU in order to make impression of sharing.

The Intel-specific top of call stack is:
clCreateSubDevicesEXT - intelocl.dll
KiUserApcDispatcher - ntdll.dll
clCreateSubDevicesEXT - intelocl.dll
cl::CommandQueue::finish - cl.hpp, line 3112

OS: Win7. CPU: Core i5. SDK: latest (June 29.)

The obvious workaround which I made is to do this copying and reading from/to GPU "by hand" - glReadPixels, glTexImage2D.

Best regards

2 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


Thanks for the reprting the issue.

The cause might be that Intel SDK doesn't support the GL texture data type you are using.
We support only formats defined in table 9.4 of the OpenCL spec.

Please check you formats and if it's not the case, please attacha short reproducer of your problem.


Leave a Comment

Please sign in to add a comment. Not a member? Join today