A guess would be some time next year — since our public launch our focus has generally been on API coverage and increasingly recently, on performance.
While performance improvements will always remain a target, we're soon at full coverage of the core CUDA APIs and will be shifting an increasing amount of effort towards developer tooling.
We haven’t yet released support for tcgen05, but we’ll deal with it the same way we deal with other inline PTX: parsing it and converting it to target-appropriate instructions together with the rest of the program.
This is something we’ve done already for the hopper-class tensorcore instructions, and the blackwell ones will map similarly, though likely with a kernel launch involved.
> Ease of programming and a giant leap in performance is one of the key reasons for the CUDA platform’s widespread adoption
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.
Weird, 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).
A 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.
I 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.
They really don't, no. Vulkan: 50 lines to allocate device memory. Cuda: One single line. What kind of extensive documentation stack do you want for functionality that is trivial in Cuda? And that exact issue continues through every little step of the way to your first usable application. I know there is VMA, it is a very poor solution to a problem that shouldn't even exist, and it only poorly addresses one of 100 parts of the API where Cuda is vastly simpler than Vulkan. Cuda also doesnt force you to use queue families but you can optionally use streams. No ridiculous descriptor management and binding in cuda, just passing pointers and handles via launch arguments. No overengineered explicit syncing mechanis in cuda, everything is nicely implicitly synced until you explicitly opt in to parallel streams. etc.
It's quite easy to set up a light abstraction layer with Vulkan where you simply use VMA, buffer device addresses and push constants for everything. No descriptor sets or bindings anything.
Alternatively you can use one of many abstraction layers that do this for you.
It absolutely isn't. After having spent 5 days not getting anything done in Vulkan, and being able to implement that same thing in a single day in Cuda (no prior experience in either API), I decided to never ever use Vulkan. It's a hopelessly overengineered API that is in dire need of a successor.
I may give it another try once it does not require a wrapper before it is remotely usable. I.e., once it has a single-line malloc without the need for third-party libs; default queues so I don't need to query and select queues; implicit sync by default and explicit sync by choice; NV-style bindless (i.e. no descriptors, just a handle); and so much more.
Of course it is a skill issue, I'm not afraid of admitting I'm not smart enough for Vulkan. That so many people have skill issues is the reason why Cuda trumps and will continue to trump Vulkan despite being vendor-locked. If you want people to actually use Vulkan, you need to remove barriers to skill-issued people like me. Poor third party wrappers like VMA that barely address one out of hundreds of issues aren't going to accomplish that, you need to resolve barriers in the core API. With a design like Cuda where there is always a default easy path, and a complex but optional path.
Of course, which is why no one is racing to adopt Vulkan, and since last year they have started multiple activities to try to turn Vulkan around to be usable for everyone, not only AAA game engines experts.
Do you want the Vulkanised 2025 and 2026 talks where this is discussed and acknowledged as a problem for Vulkan adoption?
every CUDA alternative follows the same arc: bold launch, works for 3 operations, then a Discord server where the last message is 'any updates?' from 2024
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.
Someone needs to stand up a benchmark suite for ROCM, this, and everyone else attempting it to really get the ball rolling here. SemiAnalysis could have blast with this.
The difference between ROCm and CUDA is that when a consumer GPU is released by nvidia it's supported for CUDA for about a decade. When a consumer GPU is released by AMD it's not supported by ROCm for about a year after release and then it's supported for about 3-4 years. With the RX 580 there was literally 3.7 of ROCm support.
Things might be different in enterprise but for consumer AMD GPU ROCm is a trap. It is a mayfly.
I was in graduate school for robotics when CUDA came out, and the consumer card support was critical to nvidia getting to where they are today.
High Performance Computing option A wants to set up a call with someone with the authority to spend the best part of six figures, which could maybe be part of a funding application within a year or two, if there's a strong enough case for it.
High Performance Computing option B recommends you put in an application for time at the national centre that doles out access in 15 minute increments after you outline your entire project to them.
Then along comes nvidia, with CUDA - they want a one-off payment of $100, and on the day CUDA came out, almost every CS department already had a few dozen of the cards in computers they already owned.
No huge outlay, no ongoing spending commitment, no permission or application process.
Another crucial difference is: ROCm is open source, while cuda isn't. Yes it's tough to port things to newer gpus, but in theory people did it (therock spear heading the ROCm patch for strix halo before the offical support)
In this context AdaptiveCpp should also be mentioned. Started as a SYCL implementation, but recently-ish added a compiler for compiling a CUDA dialect to GPUs and CPUs from basically all vendors
SYCL is probably the most up-to-date CUDA alternative for all intents of purposes, at least if one likes modern C++ style (and lambdas inside lambdas). Expose it as C and get bindings to any other language for relatively little effort as well since it’s just C++. With AdaptiveCpp you can also compile SYCL to CUDA so both ways work with the CUDA dialect (PCUDA).
SYCL, as well as AdaptiveCpp, is a relatively active project though and has been for several years, feeding into the C++ standards committee work and is supported by several large organisations, including US national labs and several European universities. I suppose it’s worth keeping track of for people in related fields.
I suppose it’s just really hard to beat the head start and ecosystem integration NVIDIA has with CUDA.
Alternatives exist, but little demand outside hyperscalers and special uses.
Neocloud customers just want plug-and-play CUDA. It works, it's tested, it adapts faster, and has known performance. Alternatives give no significant benefits.
Isn't the future of the industry specialized chips like those that Broadcom and Cerebras are making? I don't know how much longer I can tolerate 50 tokens per second. It feels like the dial-up era.
i'm also interested in tenstorrent. they're building GPUs with cheap GDDR6 using a fast SRAM cache, and writing their own compiler stack (used instead of CUDA) that pipelines data to the SRAM ahead-of-time so you (in theory) never need to suffer the slow speed of GDDR6 for AI workloads. also they've got built-in SFP cages where the video ports would normally be.
These efforts to support CUDA on non-Nvidia hardware seem to me misguided. If all you want is to be able to easily use non-NVidia hardware then high level tools like PyTorch already let you do that (and torch.compile uses Triton for target-specific optimization). OTOH if you want to be programming close to the metal to achieve top performance then you are probably not using CUDA in the first place, and using some CUDA translation layer on non-NVidia hardware would be an even worse idea.
In some benchmarks, SCALE beats nvcc, and we have compiler optimizations in the pipeline that will improve those numbers over time.
> If all you want is to be able to easily use non-NVidia hardware then high level tools like PyTorch already let you do that
Somewhat true, but, CUDA is significantly larger than PyTorch and there's more to Accelerated Computing than just those types of applications supported there.
> OTOH if you want to be programming close to the metal to achieve top performance then you are probably not using CUDA in the first place, and using some CUDA translation layer on non-NVidia hardware would be an even worse idea.
SOTA mlperf submissions use CUDA to achieve their high levels of performance.
It's not a "translation layer", it's a native, ahead-of-time compiler that makes full use of the native hardware features. Here's an example of a feature (Shuffles) being compiled to take advantage of native hardware instructions, resulting in speedups: https://scale-lang.com/posts/2026-01-19-optimizing-cuda-shuf...
I've played with your compiler. It's not very robust yet to production code that leans into all the libraries in the ecosystem. Solve that and you've got a killer app IMO.
On the contrary, it's great. Cuda is the single sane compute API and system, so I'll use it even if it means being vendor-locked. If my CUDA programs start running elsewhere without much intervention, that'd be amazing
I fail to see how scale is not just another form of vendor lock in, given that their compiler is not open source. Every compiler used today except cuda's is open source. And Nvidia can get away with it because of vendor lock-in.
62 comments
[ 3.1 ms ] story [ 48.0 ms ] threadAlready in 2020,
https://developer.nvidia.com/blog/cuda-refresher-the-gpu-com...
If you were to guess, when do you think your Nsight Compute alternative might be ready with your own toolchain?
While performance improvements will always remain a target, we're soon at full coverage of the core CUDA APIs and will be shifting an increasing amount of effort towards developer tooling.
This is something we’ve done already for the hopper-class tensorcore instructions, and the blackwell ones will map similarly, though likely with a kernel launch involved.
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.
https://github.com/vosen/ZLUDA
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.
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.
Having to deal with closed source opaque poorly documented stacks sucks.
Alternatively you can use one of many abstraction layers that do this for you.
I may give it another try once it does not require a wrapper before it is remotely usable. I.e., once it has a single-line malloc without the need for third-party libs; default queues so I don't need to query and select queues; implicit sync by default and explicit sync by choice; NV-style bindless (i.e. no descriptors, just a handle); and so much more.
P.s. devices and queues are generally ordered for simple programs you can just pick the 1st one.
Do you want the Vulkanised 2025 and 2026 talks where this is discussed and acknowledged as a problem for Vulkan adoption?
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 :)
Should be real simple if the HN AI echochamber is right, right?
Things might be different in enterprise but for consumer AMD GPU ROCm is a trap. It is a mayfly.
High Performance Computing option A wants to set up a call with someone with the authority to spend the best part of six figures, which could maybe be part of a funding application within a year or two, if there's a strong enough case for it.
High Performance Computing option B recommends you put in an application for time at the national centre that doles out access in 15 minute increments after you outline your entire project to them.
Then along comes nvidia, with CUDA - they want a one-off payment of $100, and on the day CUDA came out, almost every CS department already had a few dozen of the cards in computers they already owned.
No huge outlay, no ongoing spending commitment, no permission or application process.
> SCALE delivers nearly a 6x performance boost on AMD GPUs compared to using HIPIFY to convert CUDA code to AMD’s own ROCm environment
... whilst also running CUDA.
SYCL, as well as AdaptiveCpp, is a relatively active project though and has been for several years, feeding into the C++ standards committee work and is supported by several large organisations, including US national labs and several European universities. I suppose it’s worth keeping track of for people in related fields.
I suppose it’s just really hard to beat the head start and ecosystem integration NVIDIA has with CUDA.
Neocloud customers just want plug-and-play CUDA. It works, it's tested, it adapts faster, and has known performance. Alternatives give no significant benefits.
Things can change, but they are not changing now.
In some benchmarks, SCALE beats nvcc, and we have compiler optimizations in the pipeline that will improve those numbers over time.
> If all you want is to be able to easily use non-NVidia hardware then high level tools like PyTorch already let you do that
Somewhat true, but, CUDA is significantly larger than PyTorch and there's more to Accelerated Computing than just those types of applications supported there.
> OTOH if you want to be programming close to the metal to achieve top performance then you are probably not using CUDA in the first place, and using some CUDA translation layer on non-NVidia hardware would be an even worse idea.
SOTA mlperf submissions use CUDA to achieve their high levels of performance.
It's not a "translation layer", it's a native, ahead-of-time compiler that makes full use of the native hardware features. Here's an example of a feature (Shuffles) being compiled to take advantage of native hardware instructions, resulting in speedups: https://scale-lang.com/posts/2026-01-19-optimizing-cuda-shuf...
So you can diff the DOM directly on your GPU in real time.
It’s turing complete.
It literally “shits” bitcoins as a side effect
Everyone loves side effects!