Hello,
I’m having some issues running a kernel, when debugging, clEnqueueNDRangeKernel returns the value -38 which, according to the cl.h file, corresponds to CL_INVALID_MEM_OBJECT.
But when I’m checking in the specs, CL_INVALID_MEM_OBJECT is not listed among the possible returned values of clEnqueueNDRangeKernel.
Am I getting something wrong somewhere ? :shock:
Are you sure that it’s your clEnqueueNDRangeKernel call that’s returning that error code? I’m guessing you’re also calling clSetKernelArg and some form of clEnqueue[Read/Write][Buffer/Image] - is it possible that any of these calls are the issue? It would be helpful if you could post your code or at least a snippet so we can see what else might be going on.
I glanced at the 1.2 spec, and here are all (I believe…) the calls that can return CL_INVALID_MEM_OBJECT:
[ul]clCreateSubBuffer
clEnqueue[Read/Write/Copy]Buffer(Rect)
clEnqueue[Map/Fill]Buffer
clEnqueue[Read/Write/Copy/Map/Fill]Image
clEnqueueCopyImageToBuffer (or vice-versa)
clGet[Image/GetMemObject]Info
clEnqueueUnmapMemObject
cl[Retain/Release]MemObject
clSetMemObjectDestructorCallback
clSetKernelArg
clEnqueueNativeKernel
clEnqueueMigrateMemObjects
[/ul]
Unfortunately, I won’t be allowed to post any code. I know it’s not helping… ![:frowning: :frowning:](/images/emoji/twitter/frowning.png?v=6)
Each time I’m calling clEnqueueNDRangeKernel, I’m testing its return value and throwing an exception if something went wrong.
Except if the debugger is playing with me, I’m pretty sure the -38 comes from there…
I’ve been checking my kernel arguments for a while, and I found out that, for one of the buffers I pass on to the kernel, if I’m calling clSetKernelArg inside my rendering loop instead of before, I don’t have anymore troubles…
So, I Believe my memory must be corrupt somewhere and that’s why I’m getting this strange behavior. ^^
Unfortunately, I won’t be allowed to post any code. I know it’s not helping…
Hm, yeah it’s going to be hard to figure out what’s going on - maybe you can pare down your code to a smallest-possible version that has the issue but is dissimilar enough from your original code to post? Even general info would be helpful.
Each time I’m calling clEnqueueNDRangeKernel, I’m testing its return value and throwing an exception if something went wrong.
Except if the debugger is playing with me, I’m pretty sure the -38 comes from there…
You’ve probably already done this, but try differentiating the clEnqueueNDRangeKernel’s exception handling (either by making it the only one that prints an error code or by tacking on something else to print along with the error code). If clEnqueueNDRangeKernel’s truly is returning that error code, then there’s a much deeper, weirder issue here.
I’ve been checking my kernel arguments for a while, and I found out that, for one of the buffers I pass on to the kernel, if I’m calling clSetKernelArg inside my rendering loop instead of before, I don’t have anymore troubles…
So, I Believe my memory must be corrupt somewhere and that’s why I’m getting this strange behavior. ^^
You should only have to set a kernel’s arguments once. In your kernel, are you modifying your inputs? or do you have separate input and output arguments?
You should only have to set a kernel’s arguments once. In your kernel, are you modifying your inputs? or do you have separate input and output arguments?
I tried to move the call to clSetKernelArg into the rendering loop only for debugging purposes ^^, because clEnqueueNDRangeKernel is called in there. The inputs and outputs are not mixed, I only have one output and a few inputs (37… :roll:).
The inputs that aren’t modified are set once ^^. Except when the data changes, it is unloaded from the GPU then reloaded with the new values before I set the arguments again.
My calls to clEnqueueNDRangeKernel are encapsulated, so they all have the same scheme. Basically :
cl_int ciErr (CL_SUCCESS);
ciErr = clEnqueueNDRangeKernel(m_CommandQueue, pKernel->GetKernel(),
(cl_uint)szNbDim,NULL,szGlobalDim,szLocalDim,0,NULL,NULL);
if(ciErr != CL_SUCCESS)
throw MYEXCEPTION(ciErrNum);
When my program receives the exception, it breaks on the throw line. There I can directly peek at the ciErr value… So either the debugger is playing with me, either I don’t know what’s happening >_<.
That really is strange… I can’t think of anything, honestly. I suggest you start paring down your program until you get something small that replicates the issue (maybe use a dummy kernel with only 1 input?). If you can get something like that going and post it, then maybe I (or somebody else) could help debug further.
I know why!
I met the same problem.
Probably, the memory object you used is updeted, which means you have to set the arguments again:)