Ben Ashbaugh

consider enabling some KHR_ICD_TRACE messages by default

2

One of our users was recently debugging a tricky library dependency issue that was preventing one of our OpenCL devices from enumerating. Enabling KHR_ICD_TRACE messages (via the OCL_ICD_ENABLE_TRACE environment variable)...

improve version automation based on CMake project version

6

This PR has some ideas I've been considering to improve version automation. The ideal goal is to derive all versioning from the CMake project version so no other versioning has...

handle update to macos github actions workflow

1

See: https://github.com/KhronosGroup/OpenCL-ICD-Loader/pull/198 The macos-latest workflow was updated recently to macos-12, which doesn't have the gcc versions our MacOS CI is currently testing. Several options to consider: 1. Stick with macos-11...

Improve FreeBSD Support

3

see: https://github.com/KhronosGroup/OpenCL-SDK/issues/55 A minimum we should modify the OpenCL ICD loader so it checks for FreeBSD or Unix generically vs. just Linux, to fix build issues. Separately we can investigate...

Improved Unit Testing Feedback

3

I've been experimenting with alternate ways to test the OpenCL ICD loader, with the following goals in mind: 1. Use a modern unit testing framework. 1. Test as much as...

Missing links to SPIR-V-related KHR extensions

1

A few SPIR-V related KHR extensions are missing from the list of Khronos extension specifications on the registry webpage. We should add links for at least these missing KHR extensions:...

I've been generally trying to reduce the number of special `CL_HPP_FOO` preprocessor defines in these C++ headers, but I think it would be good to add a preprocessor define to...

Command Buffer Extension API Corner Cases

1

Related to #202. I hit an interesting corner case today trying to update the `opencl.hpp` mirror I have in my SimpleOpenCLSamples repo. As background, I previously enabled very basic query...

Naming Inconsistency for Extension Objects

3

We currently have a naming inconsistency for command buffer and semaphore extension objects: ```c #ifdef cl_khr_semaphore class Semaphore; #endif #if defined(cl_khr_command_buffer) class CommandBufferKhr; class MutableCommandKhr; #endif // cl_khr_command_buffer ``` Note...

We have very sparse testing for device info queries - anything of the form `clGetDeviceInfo(CL_DEVICE_XYZ)`. See review comment: https://github.com/KhronosGroup/OpenCL-CLHPP/pull/137#pullrequestreview-689346093 Is this OK? If so, we can close this issue with...