KhronosGroup / KhronosGroup/SPIRV-Cross
CUDA/OpenCL support
- Dominant language
- GLSL
- Stars
- 2.5k
- Forks
- 713
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 16
Description
Has there been any discussion regarding support for outputting CUDA and/or OpenCL C/C++ kernels? We have somewhere about 20-30 kernels currently with simultaneous implementations in CUDA and OpenCL C. The majority aren't particularly complicated and we anticipated no issues converting to GLSL for Vulkan. However, that will then be four implementations for each one (as at point no reason not to maintain a native MSL version), and would obviously be much simpler to have just one and use SIPRV-Cross (which is already planned for our rendering shaders).
The benefits of CUDA output a fairly self-explanatory. The Kernel execution mode might present a few challenges but certainly the GLCompute mode should map fairly well as a strict subset of functionality. The resulting code could then be compiled offline with nvcc or at runtime with NVRTC (which is what we do). Another substantial benefit is to be able to make use of the SPIR-V reflection API, as CUDA infamously has no reflection facilities whatsoever (I've written a few regular expressions to pluck out function definitions and arguments, but I don't exactly trust it).
For OpenCL the benefits aren't as obvious but still substantial. Primarily for targeting platforms that do not support OpenCL 2.1 (such as macOS or Nvidia) but also for running GLCompute kernels compiled from GLSL.
I've thought about taking on this project myself, but it's a substantial body of work I'm unsure if I have the resources for, and if there is interest would be better served as a community effort anyway. I imagine one could start with the MSL as a base, as it has a similar "C/C++"/physical memory style as CUDA/OpenCL. For example,
* A substantial amount of complexity is removed from no longer needing to handle graphics shaders. There's no input or output interfaces, no vertex attributes, no interpolation qualifiers, etc.
* CUDA doesn't have embedded/constexpr samplers, but OpenCL does.
* Specialization constants could map to template arguments in CUDA, or preprocessor macros in OpenCL C (OpenCL C++ has direct support).
* Buffers map pretty much identically as Metal, except CUDA omits address space.
* Textures map a little differently but not substantially so.
* Built-in types map almost identically (CUDA uses "unsigned" instead of 'u' prefix I think is about it).
* CUDA doesn't support swizzling, may have to omit a compile error if it's used.
Is this a realistic project to undertake? Has this been previously ruled out for some reason? Is there any documentation on creating new output implementations? If I do go down this road, would the project be willing to merge them, or would I be dealing with a fork situation?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing SPIRV-Cross's existing MSL output implementation and the project's documentation on creating new output implementations. Determine whether GLCompute and kernel execution modes can map to CUDA and OpenCL C/C++, then define the scope and acceptance criteria for a community-supported output backend.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100