I would like to propose an enhancement to adapt the opencl-intercept-layer to function as a native Khronos OpenCL Layer.
By enabling support for the OPENCL_LAYERS environment variable, we can allow the system's Khronos ICD Loader to load the intercept layer cleanly and officially. Currently, relying on a drop-in replacement (shim) for the system's OpenCL.dll can cause validation conflicts in certain toolchains (for example, the Khronos Loader in the DPC++ build directory terminates the intercept layer when multiple loaders are present).
Implementing the native layer hooks (like clInitLayer and clGetLayerInfo) resolves these conflicts and provides a more robust, environment-level configuration.
I have already implemented and tested this locally and will open a PR shortly for your review. Feedback is welcome!
I would like to propose an enhancement to adapt the opencl-intercept-layer to function as a native Khronos OpenCL Layer.
By enabling support for the OPENCL_LAYERS environment variable, we can allow the system's Khronos ICD Loader to load the intercept layer cleanly and officially. Currently, relying on a drop-in replacement (shim) for the system's OpenCL.dll can cause validation conflicts in certain toolchains (for example, the Khronos Loader in the DPC++ build directory terminates the intercept layer when multiple loaders are present).
Implementing the native layer hooks (like clInitLayer and clGetLayerInfo) resolves these conflicts and provides a more robust, environment-level configuration.
I have already implemented and tested this locally and will open a PR shortly for your review. Feedback is welcome!