3 ms·
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 Nv
by DiabloD3 3mo ago
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.
- dannecodez 3mo ago[dead]
- swerner 3mo agoUnfortunately, Vulkan Compute doesn’t to all the things that OpenCL, SYCL, HIP or CUDA do.
- binsquare 3mo agoYep, there are inference stacks where it just does not work without cuda in any meaningful performance
- DiabloD3 3mo agoWeird, since the most used open source inference engine is faster on Vulkan on platforms that offer multiple options, with the sole exception being Nvidia, due to poor Nvidia driver quality (which I am forced to assume is intentional, Nvidia wishes to maintain their moat after all).
- inigyou 3mo agoThere's nothing stopping any of us from writing a better Nvidia driver btw. LLMs are very helpful with reverse engineering.
- HelloNurse 3mo agoBeing fast and being as easy to program as CUDA are two different things.
- mschuetz 3mo agoA couple of years ago I evaluated both Vulkan and Cuda as a choice for future projects. I couldnt get anything done after a week in Vulkan, but had the test prototype project working after just a day in Cuda. Needless to say, I'd never ever pick Vulkan for any project after that experience. It's just way to needlessly overengineered and bloated.
- pjmlp 3mo agoI used to be big into Khronos API camp, even did my project thesis in OpenGL, up to the famous Long Peaks fail. Vulkan ended up being the same extension spaghetti as its predecessor, and Khronos was only able to come up with something thanks to AMD offering Mantle, C++ bindings and a GLSL successor only came to be thanks to NVidia (Vulkan-hpp and Slang started at NVidia). The "we build the specification", and then "the community builds the tools", leads to very poor experiences, and if it wasn't for LunarG own interests, there wouldn't even exist any kind of Vulkan SDK. What they have going is naturally the vendor independence, however we can achieve the same with middleware with the benefit of much better developer experience.
- DiabloD3 3mo agoI love how people say things like "extension spaghetti", as if all other non-standard APIs have the same problem: hardware gets new features that people want to use from that API, API gains extension to use that hardware feature. CUDA is no different, in fact, often worse. Nvidia is bad at documenting which hardware does what things, and CUDA users often have to use third party tables to figure out what hardware can't do what and disappoint customers who unwisely invested into it.
- pjmlp 3mo agoThe other platforms have better ways to deal with progress instead of "here find entries on dynamic libraries by yourself", and good luck. Profiles and API versions are much better approaches. It is no accident than the ongoing efforts to make Vulkan more friendly are moving away from extension spaghetti into profiles.
- sollycb 3mo agoPorts are very often incredibly difficult and very time consuming. One of the biggest complaints we hear from the industry is "we tried to port to X and we could never complete it". An established codebase can have years of refinement. It will take time to achieve the same with the port. And with our compiler, just using cuda is no longer putting urself inside the moat :)
- DiabloD3 3mo agoIronically, this is what people claim AI can do with a snap of the fingers. Should be real simple if the HN AI echochamber is right, right?
- pjmlp 3mo agoVulkan tooling is light years behind what CUDA offers in 2026, across programming languages, IDE tooling, graphical debuggers and libraries.