balt wrote:hence any call to clCreateBuffer will return an error if there's not enough space. So unlike my first suggestion where you check "is it gonna fit", you can just keep allocating memory, but then if it fails, you should get back to the user stating that it failed during clCreateBuffer (or whatever allocation call you're using).
That was my first thought, but it's not so easy. clCreateBuffer only creates the buffer object, not allocates the actual buffer memory you requested.
http://stackoverflow.com/questions/1690 ... on-failure:
"clCreateBuffer will not actually create a buffer on the device. This makes sense, since at the time of creation the driver does not know which device will use the buffer (recall that a context can have multiple devices). The buffer will be created on the actual device when you enqueue a write or when you launch a kernel that takes the buffer as a parameter."
If clCreateBuffer returns CL_MEM_OBJECT_ALLOCATION_FAILURE, it means that it is not enough memory to create the object itself, not the buffer, because the buffer will be allocated later.
The actual opencl calls that fails when there is not enough memory running fast multilight are clEnqueueNDRangeKernel and clEnqueueWriteBuffer. The problem, as I said, is that with some cards I get an error code from that opencl calls, as I expected, so I can stop fast multilight preview and show some error info to the user, but other cards just crash or starts going crazy. OpenCL is very tricky, and the differences between AMD/NVIDIA/INTEL and WIN/LINUX/OSX implementations are desperating
