bheisler
commented
5 years ago Therefore, I am skeptical that you could reach parity with upstream CUDA, and keep that position over time.
I think it's possible because most of the work is already done. The LLVM NVPTX backend and bindgen-generated wrappers around the CUDA API get us most of the way there. I just need to improve rustc so it stops crashing and generating invalid PTX files, and build out some supporting tooling.
Yeah, true parity with C is probably an overly ambitious goal, but that doesn't mean things can't be made better than they are.
If you don't like NVidia, you're perfectly free to build out your own tools. Is there an LLVM backend for SPIR-V? Is it integrated into rustc yet? That would probably be the place to start.
peterhj
crinklywrappr
Dithermaster
kgreenek
pinnaclesystemsgroup
A couple of comments from someone who has played with GPGPU in the past, before concluding that it's currently too much of a minefield compared to how much of interest it is to my workplace.
Modern OpenCL (2.1+) does not force the use of OpenCL C anymore, but instead ingests a standardized variant of LLVM's IR called SPIR-V. It is then up to the GPU driver to transpile that into a device-specific binary, a much easier task than compiling a dialect of of C. Sadly, NVidia do not care much about compute standards, like any company in a position of power, and will not support anything higher than OpenCL 1.2 with some beta-quality 2.0 extensions. They also changed their tools (profiling, debugging...) a while ago in order to prevent them from correctly operating on OpenCL programs as they did before. The situation is so bad that a colleague of mine is transpiling his OpenCL code to CUDA when targeting NVidia GPUs (this is reasonably easy to do, unlike the reverse operation).
Unlike OpenGL, Vulkan was built to handle compute and to only accept SPIR-V shaders from day one. Compute is not an extension that is grafted on top of the graphics spec, every hardware that supports graphics is also required to support compute in order to comply with the Vulkan spec. For a while, NVidia tried to fight the use of SPIR-V by providing a vendor-specific extension to their Vulkan implementation which allows it to ingest GLSL. But since they do not have a monopoly in the graphics space, they eventually had to surrender and deprecate that extension. Personally, if I had to get back into GPU computing, I would seriously consider using Vulkan for this purpose nowadays. This would protect me from NVidia's anti-competitive practices (unlike Microsoft and Apple, they are not powerful enough to build a proprietary graphics ecosystem), at the cost of losing some manual optimization headroom (a few nice OpenCL concepts are not yet exposed in the Vulkan API) and portability (OpenCL can also target CPUs and FPGAs, Vulkan currently cannot).
OpenCL and Vulkan are both meant as infrastructure, rather than for direct end-user consumption. A developer will typically write a few hundred lines of "engine" code at the beginning in order to handle device detection and selection, then re-use that engine across all of his subsequent GPU codebases. CUDA has a similar layer under the hood, called the CUDA Driver API. If you want something like the "regular" CUDA API in the OpenCL ecosystem, you may want to look up SyCL, AFAIK no similar project has been attempted in Rust at this point in time.
Building an (end-user) CUDA equivalent in Rust needs an enormous amount of work, something which "regular" CUDA gets for free due to NVidia's corporate backing. Therefore, I am skeptical that you could reach parity with upstream CUDA, and keep that position over time. Further, before you go on and decide to help NVidia's proprietary technologies with your effort, you may want to look up how they treat their customers, and anything that looks like a threat to their monopoly:
Therefore, in my opinion, any open-source project which cares about a healthy hardware ecosystem should be doing anything it can to break NVidia's monopoly, and leave them the work of trying to sustain it.