CL_OUT_OF_RESOURCES for 2 millions floats with 1GB VRAM?

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 decla开发者_运维问答red CL_OUT_OF_RESOURCES.

---

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.

---

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.

---

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...

---

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.