Ben Ashbaugh

> My personal preference would be to not set `binary_status[i]`. It makes the implementation simpler and doesn't take any information away from the application. The application can't know which binary...

Brief discussion summary: * Layers that call `atexit` have the potential to be a big problem, although unfortunately this is the only way to reliably do any sort of post-processing...

This was discussed here: https://github.com/KhronosGroup/OpenCL-CTS/pull/2058#pullrequestreview-2345813923 And here: https://github.com/KhronosGroup/OpenCL-CTS/pull/2108 I think unifying the behavior will require a spec change, unfortunately. Maybe if/when we ever bring `cl_khr_fp16` into the core spec?

Recording discussion from working group teleconference: this is an issue merging with the cl_khr_fp16 spec. Need to document that this functionality is required, but only when the extension is supported.

Regarding: > Can we put information about thread safety into the XML file and auto-generate the right text into the spec? In the Vulkan XML file, the parameters that are...

Discussed in the March 18th teleconference: * We will split the changes into two. * The short-term change will simply add command buffer APIs to the existing appendix. * The...

Thank you for the feedback! > * I can see that the ability to request individual SVM features can be very powerful, if implementations are happy to carry the burden...

Mentioned in the January 7th teleconference: I have OpenCL Intercept Layer support for unified SVM done and in a branch, which I will try to keep up-to-date with the latest...

Hmm, `cl_khr_subgroup_rotate` seems to have the same issue. * Fails with OpenCL C 1.2: https://godbolt.org/z/d61vTsnsG * Passes with OpenCL C 3.0: https://godbolt.org/z/8E19dna8Y I don't see any feature macros associated with...

Discussed in the March 20th OpenCL tooling subgroup. In summary: * The most reliable (and hence recommended) method to have the right extension and feature macros defined is to do...