OpenCLOn12 VS GLSL

The SPIR-V OpenCL profile is suitable, the Vulkan one is much less suitable. (In the you can’t even transpile OpenCL C 1.2 to it fully, with quite heavily limited pointers…)

Metal has the best GPGPU story of the compute APIs, with D3D12 coming second after that. Both at least can have OpenCL C transpiled without catches to them…

Microsoft is writing CLon12 on that front: https://github.com/microsoft/OpenCLOn12

> OpenCL does not work. There's some bits about intel [& amd] GPUs, but nada on nvidia

This is planned to be fixed. WSL2’s GPU support currently doesn’t provide a path to provide an alternate OpenCL loader ICD location. (And not for OpenGL either)

Microsoft is developing CLon12 at https://github.com/microsoft/OpenCLOn12 as the option to provide OpenCL out of the box.

OpenCL really is your best bet for a cross-platform GPU-capable framework. OpenCL 3.0 cleared out a lot of the cruft from OpenCL 2.x so it's seeing a lot more adoption. The most cross-platform solution is still OpenCL 1.2, largely for MacOS, but OpenCL 3.0 is becoming more and more common for Windows and Linux and multiple devices. Even on platforms without native OpenCL support there are compatibility layers that implement OpenCL on top of DirectX (OpenCLOn12) or Vulkan (clvk and clspv).

You're looking for this repo

You have access to physical (u64) global memory pointers through buffer_reference in GLSL, note you should be using buffer_reference2

On April 27, 2023 the Vulkan® Ray Tracing TSG released the VK_KHR_ray_tracing_position_fetch extension, which exposes the ability to fetch vertex positions from an acceleration structure hit when tracing rays. The SPIR-V SPV_KHR_ray_tracing_position_fetch and GLSL GL_EXT_ray_tracing_position_fetch extensions have also been released to provide SPIR-V and GLSL support for this functionality.

You can also have general extensions that are only supported on some hardware, for instance NVIDIA supports all of these extensions on OpenGL that add support for Vulkan's thread subgroup operations while AMD only supports these extensions and a few others that add support for similar features to the extension that NVIDIA supports, but with way more restrictions.

GL_NV_ray_tracing is a vendor extension, but it does exist.

According to this document, one should be able to extract those values through

The reports of my death are greatly exaggerated

https://github.com/KhronosGroup/GLSL/blob/master/extensions/...

I don't think there's away. For Vulkan, there's GL_EXT_nonuniform_qualifier which allows you to index with gl_InstanceIndex but AFAIK it's not available for OpenGL.

AMD hardware works a little differently, and for that you have to write a waterfall loop with subgroup instructions to get the correct behavior (since GL_EXT_nonuniform_qualifier doesn't exist in OpenGL GLSL). The loop might look like this (you would use it the same way as NonUniformEXT in Vulkan GLSL).