# CL\_MEM\_OBJECT\_ALLOCATION\_FAILURE upon clEnqueueNDRangeKernel **URL:** \ **Category:** OpenCL\ **Created:** [June 16, 2015, 10:13am UTC](https://community.khronos.org/t/cl-mem-object-allocation-failure-upon-clenqueuendrangekernel/6624 "2015-06-16T10:13:51Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![whizkid667](https://community.khronos.org/letter_avatar_proxy/v4/letter/w/e79b87/32.png) [@whizkid667](https://community.khronos.org/u/whizkid667)\ **Post date:** [June 16, 2015, 10:13am UTC](https://community.khronos.org/t/cl-mem-object-allocation-failure-upon-clenqueuendrangekernel/6624/1 "2015-06-16T10:13:51Z")
I have 5 Kernels, which keeps processing a finite amount of data. Multiple cl\_mem objects are created, some which are used only in a single kernel and some which are shared across kernels. I keep getting CL\_MEM\_OBJECT\_ALLOCATION\_FAILURE while enqueuing the 3rd Kernel. However, when I reduce the data am getting the error while enqueuing the 4th Kernel (The 3rd Kernel enqueue works fine). There are no errors returned in any of the clCreateBuffer calls. I suspected it to be a memory issue. For the first (larger) set of data, almost 42MB memory (Global Memory) (cl\_mem objects) was allocated before the 3rd Kernel enqueue failure. For the second (smaller) set of data, only 1.48MB memory (Global Memory) was allocated before the 4th Kernel enqueue failure. My device capabalities queries yield CL\_DEVICE\_MAX\_MEM\_ALLOC\_SIZE as 256MByte and CL\_DEVICE\_GLOBAL\_MEM\_SIZE 1024MByte. Am allocating much less than these values. Fearing, it could be a problem in the kernel code, I commented out the entire Kernel code, except the parameters and still am getting the same. So am completely lost in understanding this issue. The callback notification function set to the context (in clCreateContext) didn’t provide any additional details. Is there any way to get details regarding which memory object allocation failed and for what reasons? Thanks in advance… ## Running OpenCL 1.1 These are the device details : ## Device Details ## CL\_DEVICE\_NAME: GeForce GTX 460 CL\_DEVICE\_VENDOR: NVIDIA Corporation CL\_DRIVER\_VERSION: 340.62 CL\_DEVICE\_VERSION: OpenCL 1.1 CUDA CL\_DEVICE\_OPENCL\_C\_VERSION: OpenCL C 1.1 CL\_DEVICE\_TYPE: GPU CL\_DEVICE\_MAX\_COMPUTE\_UNITS: 7 CL\_DEVICE\_MAX\_WORK\_ITEM\_DIMENSIONS: 3 CL\_DEVICE\_MAX\_WORK\_ITEM\_SIZES: 1024 / 1024 / 64 CL\_DEVICE\_MAX\_WORK\_GROUP\_SIZE: 1024 CL\_DEVICE\_MAX\_CLOCK\_FREQUENCY: 1350 MHz CL\_DEVICE\_ADDRESS\_BITS: 32 CL\_DEVICE\_MAX\_MEM\_ALLOC\_SIZE: 256MByte CL\_DEVICE\_GLOBAL\_MEM\_SIZE: 1024MByte CL\_DEVICE\_ERROR\_CORRECTION\_SUPPORT: no CL\_DEVICE\_LOCAL\_MEM\_TYPE: local CL\_DEVICE\_LOCAL\_MEM\_SIZE: 47KByte CL\_DEVICE\_MAX\_CONSTANT\_BUFFER\_SIZE: 64KByte CL\_DEVICE\_QUEUE\_PROPERTIES: CL\_QUEUE\_OUT\_OF\_ORDER\_EXEC\_MODE\_ENABLE CL\_DEVICE\_QUEUE\_PROPERTIES: CL\_QUEUE\_PROFILING\_ENABLE CL\_DEVICE\_IMAGE\_SUPPORT: 1 CL\_DEVICE\_MAX\_READ\_IMAGE\_ARGS: 128 CL\_DEVICE\_MAX\_WRITE\_IMAGE\_ARGS: 8 ---
**Author:** ![Bilog](https://community.khronos.org/letter_avatar_proxy/v4/letter/b/a183cd/32.png) [@Bilog](https://community.khronos.org/u/Bilog)\ **Post date:** [June 16, 2015, 9:12pm UTC](https://community.khronos.org/t/cl-mem-object-allocation-failure-upon-clenqueuendrangekernel/6624/2 "2015-06-16T21:12:32Z")
You are seeing the effect of the so-called delayed or lazy allocation, which is a very common technique used in many implementations. Basically, when an OpenCL buffer is created, it is not instantly physically allocated on the device. Instead, allocation is delayed to the time it is used. This is why you are seeing the error at different times depending on array size. Lazy allocation is allowed by the standard, and is not a problem per se. The problem comes from the fact that many implementation do not support the other side, which is buffer eviction (i.e. moving buffer out of the device when it’s not used): to work around this, you will have to manage your buffers manually, releasing them when not in use.