# OpenCL - Kernel outputs image correctly but values don't show up on Host side

So once again it's related to my previous path tracer project. The path tracer routines are inside the kernel and for simplicity I'm just outputting a predefined color value ignoring all the lengthy calculations.

I'm using OpenCL-GL interoperability to create CL image buffer from GL Renderbuffer object, after the kernel has completed I blit from this RBO to the default Framebuffer. The program works fine on GPUs (ATI/NVIDIA) and (Intel HD graphics) but when I try to run this on Intel CPU (5th gen) nothing shows up. I tried to debug using printf's in kernel and it seems that the kernel does infact write the proper color value. However after the kernel finishes and I try to blit or read it using GlReadPixels() nothing shows up.

A basic flow of my program is like this

create Image buffer using clCreateFromGLRenderbuffer()
Set kernel arguments...

GlFinish()
clEnqueueAcquireGlObjects()
EnqueueKernel()
clEnqueueReleaseGlObjects()
clFinish()

Now either blit or try reading through glReadPixels from the color attachment of the RBO.


One more strange thing that's happening is that when running on CPU, the first iteration runs ok, however the second time the kernel is enqueued it throws CL_INVALID_OPERATION. I tried looking up and apparently this error is not thrown by EnqueueNDrangeKernel but by clBuildProgram and some other functions.

Do note that I am not using any sort of Read/Write Buffer or Map/Unmap memory objects, as imo this shouldn't be necessary since I don't intend to use it. I'm just passing ownership of the resources through Acquire and Release calls.

If anybody has any idea as to why this behavior can occur, I'd appreciate it.

Update :- It seems this more of a bug related to Intel OpenCL runtime. I tried changing my image buffer created from RBO from CL_MEM_READ_WRITE to CL_MEM_WRITE_ONLY and atleast the program doesn't crash now. It outputs the correct value on first iteration but subsequent iterations still show nothing. I'll be closing this question as it seems more specific and is better suited at intel opencl forums i guess.

• I'm voting to close this question as off-topic because this looks like a bug in the Intel OpenCL runtime and is better off on Intel's forums. – gallickgunner Oct 9 at 11:50