Ben Ashbaugh

Discussed in the August 20th teleconference. There is some interest in lifting the OpenCL C restriction (probably as an extension?), which should be a pretty light lift for most implementors...

Related: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/issues/2510 We have had some discussion about this in the OpenCL tooling TSG teleconferences, also.

Discussed in the December 3rd teleconference: * For `cllayerinfo`, we filed https://github.com/KhronosGroup/OpenCL-ICD-Loader/issues/247 for tracking. * For `saxpy` and `saxpycpp`, Qualcomm will investigate why the sample is failing on their implementation....

I remember being confused about this also. I read "Each extension that is supported by all devices associated with this platform must be reported here" to mean: * If an...

https://github.com/KhronosGroup/OpenCL-CTS/pull/2172 updates the test so it works the way I expect it should work. It's passing on most of the implementations I've tested, though not all: one implementation is returning...

Discussed in the December 10th teleconference. Our current thinking is: 1. If an extension is supported by all of the devices in the platform then the extension must be reported...

> I think the more interesting aspect here is consistency. What if an implementation also reports "purely platform extensions" as device ones? What if applications start to rely on it...

Merging as discussed over email.

Here are some draft tests to check how an implementation behaves when it is passed a size of zero for these SVM APIs and a few others: * https://github.com/KhronosGroup/OpenCL-CTS/pull/2431 Most...

Discussed in the November 4th memory subgroup: * We aren't going to require any new behavior for implementations that do not support `cl_khr_unified_svm`. * We are going to test this...