Ben Ashbaugh

I've asked to add this to tomorrow's teleconference agenda. My recommendation would be to remove this document. We had some ideas a while back (probably in 2019) to support "compiler...

Discussed in the March 19th teleconference. We're going to sunset this document. I'll make a PR to unlink it from the resource guide shortly, and it's fine that it is...

The "conditions" are currently used by the extension header generation scripts: https://github.com/KhronosGroup/OpenCL-Headers/blob/59452533d2afa817bc2dc0da4f783097f4cdbcb0/scripts/cl_ext.h.mako#L307 I'm OK doing something like this PR to remove redundancy, but we'll need to update the header generation...

Leaving this open until the discussion around re-importing semaphore handles is closed.

Merging as discussed in the July 9th teleconference.

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

Interesting question. We currently say for the description of the `svm_ptr` argument to `clEnqueueSVMUnmap`: > svm_ptr is a pointer that was specified in a previous call to [clEnqueueSVMMap](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html#clEnqueueSVMMap). If svm_ptr...

I tried a couple of Intel OpenCL implementations and it looks like our CPU implementation returns `CL_INVALID_VALUE` for this case and our GPU implementation returns `CL_SUCCESS`. I saw similar mixed...

Discussed in the August 22nd teleconference: - Implementations should return an error in this case - `CL_INVALID_VALUE`. - We don't currently have a CTS test for this case, but we'll...

I have a (draft) PR written up that adds this error condition in #979, but I'm starting to have second thoughts whether it is actually possible to reliably return an...