11–20 of 82 posts
Its easier to just get rid of your legacy code entirely and use Vulkan for compute, or have your compiler emit SPIR-V directly. No reason to tie yourself to Nvidia's moat.
Earlier quoted context omitted.
Including stuff like Fortran, Haskell, Java, .NET via PTX, Python JIT, IDE tooling integration with major IDEs, graphical GPU debugging and profiling, libraries and co? Then I guess all the best.
This post has some serious peanut-gallery vibes.
There's nothing wrong to run CUDA on non-Nvidia hardware. CUDA has an interface that is reasonably well-designed, well-documented/reverse-engineered, and battle-tested for decades. What we need is not to invent another interface just under the name of 'open standard', but to implement the same interface. ROCm is exactly doing this, and so are other hardware SDKs such as MooreThread and Alibaba T-Head.
Its easier to just get rid of your legacy code entirely and use Vulkan for compute, or have your compiler emit SPIR-V directly. No reason to tie yourself to Nvidia's moat.
Unfortunately, Vulkan Compute doesn’t to all the things that OpenCL, SYCL, HIP or CUDA do.
Most of these "alternatives" focus on CUDA C++, and overlook what actually makes CUDA interesting. Already in 2020, https://developer.nvidia.com/blog/cuda-refresher-the-gpu-com...
This, so much. Other platforms continue to ignore developer UX, but it's one of the main things that get's new users onboard and keeps old users around.
Its easier to just get rid of your legacy code entirely and use Vulkan for compute, or have your compiler emit SPIR-V directly. No reason to tie yourself to Nvidia's moat.
Needless to say, I'd never ever pick Vulkan for any project after that experience. It's just way to needlessly overengineered and bloated.