Actually, in my case also enqueue_kernel returned -1 error code after a limited number calls. The actual number may vary with queue size and packet size. However, there was no hang as you mentioned earlier.
Regarding the error code, I was expecting CL_ENQUEUE_FAILURE not CL_DEVICE_NOT_FOUND. That I'll check with the related team.
Then tried this:
err[threadId]= CLK_OUT_OF_RESOURCES ;
err[threadId]= CLK_INVALID_NDRANGE ;
err[threadId]= CLK_INVALID_QUEUE ;
err[threadId]= CLK_INVALID_EVENT_WAIT_LIST ;
err[threadId]= CLK_INVALID_ARG_SIZE ;
adding CL_ENQUEUE_FAILURE makes it say "undeclared identifier" since I'm compiling with -g
It should be CLK_ENQUEUE_FAILURE instead of CL_ENQUEUE_FAILURE (seems a typo in this page enqueue_kernel ).
Actually the error code -1 was against CLK_ENQUEUE_FAILURE. Earlier I was comparing error value -1 with host-side code (CL_DEVICE_NOT_FOUND) which was not correct.
Also, as I've come to know, enqueue_kernel may not provide any extra error information when "-g" is used. In fact, it's an optional feature, not a requirement as per the spec. So, implementation may ignore the detail.
Thank you very much. I will be paying more attention to optionality/vendor-ignorability of a feature next time I open a new issue discussion.
Maybe I should have implemented my own producer-consumer structure before enqueueing on default queue. But that could be a performance hit because of constantly checking something in global memory.
Should I keep developing opencl programs or start vulkan? Because I heard opencl will join to vulkan. Will there be a steep vulkan learning curve be needed in future?