Earlier quoted context omitted.
OpenCL is old, and everyone seemingly wants to abandon it, but it's your only option for a bunch of configurations (such as AMD on Windows, even though AMD has pulled all their OpenCL stuff from their website). As someone who's done a fair bit of SIMD programming on CPU, and heard many scream that wide SIMD (like AVX512) is pointless when you have GPGPU, it's certainly eye-opening to see how poor a state cross-platfo…
Vulkan supports integer operations just fine, but tool support for just about everything is extremely primitive. Sizes other than 32 bits are available, but generally as an option. You can check https://vulkan.gpuinfo.org/listfeaturescore10.php to see the fraction of drivers that support the various integer sizes (and lots other optional features).
Most examples seem to be using GLSL shaders for the kernel, but posts seem to indicate it uses SPIR-V as input [https://community.khronos.org/t/is-a-vulkan-compute-shader-d...]. And then you have threads like this [https://community.amd.com/t5/drivers-software/amd-dropped-sp...] saying that SPIR-V isn't supported on the AMD's Windows driver (I had similar issues myself trying to get SYCL examples to run), though I see other places running Vulkan Compute stuff on AMD+Windows. Maybe that only applies to SPIR-V with an OpenCL runtime?
Diagrams [https://www.khronos.org/assets/uploads/apis/2020-spir-landin...] seem to indicate that you can feed stuff like OpenCL and SYCL into SPIR-V (and then Vulkan Compute) instead of GLSL. For the former case, would you essentially still be using OpenCL, but just with a different runtime? (though articles like this [https://linuxreviews.org/The_State_Of_OpenCL_To_Vulkan_Compu...] seem to suggest OpenCL -> Vulkan isn't in a good state)