5 ms·
That's a problem on a different level of the CUDA stack. Having a compiler that takes a special C++ or python dialect and compiles it to GPU suitable llvm-ir a
by KeplerBoy 2y ago
That's a problem on a different level of the CUDA stack.
Having a compiler that takes a special C++ or python dialect and compiles it to GPU suitable llvm-ir and then to a GPU binary is one thing (and there's progress on that side: triton, numba, soonish mojo), being able to launch that binary without going through the nvidia driver is another problem.
- shmerl 2y agoYeah, the latter one is more useful for effective lock-in breaking.
- codedokode 2y agoCannot Vulcan compute be used to execute code on GPU without relying on proprietary libs? Why not?
- Conscat 2y agoYou still require a Vulkan driver to do anything with it. Until last year, Nvidia hardware required a proprietary Vulkan driver (prior to Nvvk), and anything pre-Pascal still requires that.
- codedokode 2y agoYes but you can use any GPU with Vulkan, not only NVIDIA.
- cyber_kinetist 2y agoVulkan Compute's semantics are limited by SPIR-V and thus cannot implement all of the features CUDA provides (ex. there is no proper notion of a "pointer") Also it's much more convenient to use plain C++ rather than a custom shading language, especially if you're writing complex numerical code or need some heavy templated abstractions to do powerful stuff. And the CUDA tooling itself is just much easier to use compared to Vulkan, with its seamless integration of host / device code.
- nsajko 2y ago> [...] there's progress [...] Don't forget about Julia!
- KeplerBoy 2y agoand jax, tinygrad and halide. God it's such an awesome time to be into that stuff.