Kévin Petit

Agree this should be supported by the build system but clvk tends to require fairly recent versions of the dependencies so not sure how often the system packages would be...

Discussed on the 2020/09/08 teleconference: - Having the behaviour mandated in the core specfication makes it possible to build generic tooling around the properties. - We need to decide the...

Observed in the 2024/05/14 teleconference: we do have _some_ of the information in the XML already and we are using it in header generation: ``` ```

As discussed in the 2025/03/25 memory TSG, here's an RFC PR to remove all Vulkan/CL interop testing using optimally-tiled images. This PR seems to pass the few simple tests I've...

Discussed in 2024/09/24 teleconference. Requiring the flush on each call to `clReleaseCommandQueue` has unwanted side-effects. Consensus that the intent likely was to free applications from having to insert explicit flushes...

Thanks for the initial analysis, that's great input. I think we've reached the point where we need to take a step back and figure out how we want the code...

A single `cl_command_properties_khr` property type sounds like a better direction to me. It's not like our approach to properties is type safe anyway...

Merging as discussed in the 2025/04/08 teleconference.

See point 2 on related https://github.com/KhronosGroup/OpenCL-Docs/issues/171 as well.

Just bumped into this again. We are missing conversion rules for `CL_UNORM_INT_101010_2` in both the OpenCL C and SPIR-V environment specifications. We will also need rules for https://github.com/KhronosGroup/OpenCL-Docs/pull/1223 either as...