It seems like 2 million floats should be no big deal, only 8MBs of 1GB of GPU RAM. I am able to allocate that much at times and sometimes more than that with no trouble. I get CL_OUT_OF_RESOURCES when I do a clEnqueueReadBuffer, which seems odd. Am I able to sniff out where the trouble really started? OpenCL shouldn't be failing like this at clEnqueueReadBuffer right? It should be when I allocated the data right? Is there some way to get more details than just the error code? It would be cool if I could see how much VRAM was allocated when OpenCL declared CL_OUT_OF_RESOURCES.
4 Answers
I just had the same problem you had (took me a whole day to fix). I'm sure people with the same problem will stumble upon this, that's why I'm posting to this old question.
You propably didn't check for the maximum work group size of the kernel.
This is how you do it:
size_t kernel_work_group_size;
clGetKernelWorkGroupInfo(kernel, device, CL_KERNEL_WORK_GROUP_SIZE, sizeof(size_t), &kernel_work_group_size, NULL);
My devices (2x NVIDIA GTX 460 & Intel i7 CPU) support a maximum work group size of 1024, but the above code returns something around 500 when I pass my Path Tracing kernel. When I used a workgroup size of 1024 it obviously failed and gave me the CL_OUT_OF_RESOURCES error.
The more complex your kernel becomes, the smaller the maximum workgroup size for it will become (or that's at least what I experienced).
Edit:
I just realized you said "clEnqueueReadBuffer" instead of "clEnqueueNDRangeKernel"...
My answer was related to clEnqueueNDRangeKernel.
Sorry for the mistake.
I hope this is still useful to other people.

- 1,673
- 22
- 30
-
Hey thank you. You are right! I was using device max work group size instead of kernel max work group size. Changed that fixed it :). – Gamer Mar 25 '14 at 11:37
From another source:
- calling clFinish() gets you the error status for the calculation (rather than getting it when you try to read data).
- the "out of resources" error can also be caused by a 5s timeout if the (NVidia) card is also being used as a display
- it can also appear when you have pointer errors in your kernel.
A follow-up suggests running the kernel first on the CPU to ensure you're not making out-of-bounds memory accesses.

- 4,175
- 1
- 15
- 17
Not all available memory can necessarily be supplied to a single acquisition request. Read up on heap fragmentation 1, 2, 3 to learn more about why the largest allocation that can succeed is for the largest contiguous block of memory and how blocks get divided up into smaller pieces as a result of using the memory.
It's not that the resource is exhausted... It just can't find a single piece big enough to satisfy your request...

- 1
- 1

- 4,175
- 1
- 15
- 17
-
This makes sense, thanks for pointing it out. Is there a way to analyze what the fragmentation of heap memory looks like on the GPU when the failure occurred? – smuggledPancakes Oct 21 '10 at 16:28
-
Somehow I doubt thats really the problem, since the gpu memory should generally not be fragmented enough for that. Afterall 8MB isn't really that much on a 1GB card (exspecially since the driver should be able to pull currently unused memory to mainmemory) and allocations of gpu memory are typically relatively chunky. So it seems likely that you must be close to the memory limit if you see such issues due to fragmentation anyhow and if it's a normal grapic card based system (opposed to e.g. tesla) I doubt the driver would not intervene at that point (by killing some contexts). – Grizzly Oct 21 '10 at 17:07
-
I still cannot figure out how to pin down this problem. I get the CL_OUT_OF_RESOURCES exception even if I put in clFinish() calls between my OpenCL calls. Why does it get triggered when I do a clEnqueueReadBuffer()? – smuggledPancakes Oct 21 '10 at 20:58
-
@user464095: Random guess: Are you specifying a local_work_size to clEnqueueNDRangeKernel()? – Eric Towers Oct 21 '10 at 21:39
-
@user464095: clEnqueueReadBuffer() has only two error modes, CL_MEM_OBJECT_ALLOCATION_FAILURE and CL_OUT_OF_HOST_MEMORY, that could map to a CL_OUT_OF_RESOURCES. Do you get the exception before clEnqueueReadBuffer() returns? (If so, this exception is probably due to a prior call.) – Eric Towers Oct 21 '10 at 21:40
-
@user464095: Actually, it's rather likely that the problem is a call prior to clEnqueueReadBuffer(). That's usually the first time that a failure at the GPU actually percolates out to your code. – Eric Towers Oct 21 '10 at 22:02
-
A local_work_size of {256,1,1} is specified in clEnqueueNDRangeKernel. I think I am just going to have to probe my code with clEnqueueReadBuffer() calls in order to try and isolate where the failure actually occurs. It feels like a indexing problem, since it only happens when certain paremters are really big. I just can't prove it yet. It could also be some weird OpenCL quirk. – smuggledPancakes Oct 22 '10 at 12:51
Out of bounds acesses in a kernel are typically silent (since there is still no error at the kernel queueing call).
However, if you try to read the kernel result later with a clEnqueueReadBuffer(). This error will show up. It indicates something went wrong during kernel execution.
Check your kernel code for out-of-bounds read/writes.

- 8,235
- 1
- 26
- 36