Clarification on zero sizes in clEnqueueXXXBuffer APIs

[frasercrmck]

This might be a simple question to answer as it's arguably the status quo in the specification, but because it has caused a discussion internally I'd like to ask for clarification about whether the clEnqueue(Read|Write|Copy|Fill)Buffer functions allow a size parameter of 0.

As far as I can determine, the specification doesn't say it is an error so it's presumably not an error. I can't see any test in the OpenCL-CTS testing that it's an acceptable (or unacceptable) value, though. Should it? If so, I can take this issue over there.

[bashbaug]

I think that the zero size is valid. This was a change in OpenCL 2.1, along with the "zero-sized enqueue" feature. If you look carefully, in the OpenCL 2.0 spec it was an error to specify a size of zero, say from clEnqueueReadBuffer:

CL_INVALID_VALUE if the region being read or written specified by (offset, size) is out of bounds or if ptr is a NULL value or if size is 0.

But this condition is absent in the latest specs:

CL_INVALID_VALUE if the region being read or written specified by (offset, size) is out of bounds or if ptr is a NULL value.

For the Khronos folks, this was discussed in old Bugzillas 8677 (originally) and then Bugzilla14651 (for these sizes specifically).

I would not be at all surprised if CTS tests were missing for this feature though, so I think this issue should move to OpenCL-CTS.

[frasercrmck]

Thanks for the clarification, @bashbaug!

Forgive my asking, but is the unified spec supposed to represent all OpenCL versions? Should the unified specification be updated to mention that before OpenCL 2.1, these functions return CL_INVALID_VALUE when size is 0? Of course, I can see that this would bloat the spec, but it seems like it could be important information for people implementing, using, or debugging an OpenCL 1.2 implementation.