NVIDIA’s dominance in AI hardware is a software story as much as a chip story. Comparing CUDA, AMD’s ROCm, and the slow, still-unfinished emergence of SYCL and WebGPU as genuinely portable alternatives.
Every account of NVIDIA’s position in AI computing eventually arrives at the same detail: it is not just that NVIDIA makes fast chips, it is that nearly the entire software stack the industry runs on was written against one company’s proprietary programming interface. CUDA has been NVIDIA-only for its entire eighteen-year existence, and everyone else building GPU compute software, AMD, Khronos, the browser vendors, has spent the years since trying to answer the same question: how do you get developers off a platform when the platform got a decade’s head start and the entire ecosystem of libraries, tutorials, and trained engineers now assumes it exists?
A Fifteen-Year Head Start
NVIDIA hired Brook creator Ian Buck in 2004 and paired him with GPU architecture director John Nickolls to turn an academic research language into a product. CUDA shipped publicly in 2007 alongside the Tesla-architecture G80 GPU, giving developers a C-like language with direct, low-level control over GPU memory and thread scheduling, running exclusively on NVIDIA silicon. That exclusivity was never hidden or incidental, it was the point: CUDA was a proprietary platform meant to make NVIDIA hardware the only sensible target for anyone who wanted that level of performance.
The current market numbers make the outcome of that strategy hard to argue with. Independent semiconductor analyst TechInsights estimated NVIDIA shipped 98% of all AI GPUs in 2023 by unit volume, and Jon Peddie Research separately put NVIDIA’s share of the broader discrete GPU market at 90% as of the third quarter of 2024. A related but distinct measure, the value of the entire data-center AI chip market including non-GPU accelerators, put NVIDIA closer to 65% in 2023, with Intel and AMD’s other accelerator lines making up most of the rest, a reminder that “market share” numbers in this space vary a lot depending on exactly what is being counted.
ROCm’s Answer, and Its Own Tell
AMD’s open-source answer, ROCm, has existed since 2016, giving developers a CUDA-equivalent programming stack that AMD does not control exclusively and that in principle could run on other vendors’ hardware too. But the most revealing part of ROCm’s design is not the parts that compete with CUDA, it is the part that translates from it. ROCm’s HIP layer deliberately mirrors CUDA’s API almost function for function, hipMalloc next to cudaMalloc, hipMemcpy next to cudaMemcpy, and AMD ships a tool called HIPIFY specifically to mechanically convert existing CUDA source code into HIP source code that can then run on either AMD or NVIDIA hardware.
That design choice is itself evidence of how deep the lock-in runs. AMD did not bet on convincing developers to learn a new, independent API from scratch. It bet on meeting them where they already were, inside a codebase written for CUDA, and building a mechanical off-ramp. The strategy concedes the point it is trying to solve: CUDA is the gravity well every other GPU compute platform now has to be designed around, including the ones explicitly built to compete with it.
SYCL and WebGPU: Portability by Committee
The vendor-neutral path runs through standards bodies, and standards bodies move slowly relative to a single company shipping its own product. Khronos Group announced SYCL, a single-source C++ layer that can target CUDA, ROCm, OpenCL, and Intel’s Level Zero backend from one codebase, in March 2014, seven years after CUDA’s public release. It took Khronos until February 2021 to ship SYCL 2020, the revision most developers consider genuinely modern and usable, which is fourteen years after CUDA first shipped and five years after AMD’s ROCm was already in developers’ hands.
WebGPU followed an even longer road from a different direction entirely: browsers. The W3C’s “GPU for the Web” community group formed in February 2017 to build a portable graphics and compute API that could replace WebGL across every browser without depending on any one vendor’s driver stack. Chrome and Edge shipped initial support in April 2023, six years after the group’s formation. Safari did not follow until June 2025, and Firefox until July 2025, meaning it took upward of eight years from the standardization effort’s start for WebGPU to be available across all three major browser engines.
| Platform | Vendor-neutral? | Years behind CUDA at full maturity |
|---|---|---|
| CUDA | No, NVIDIA only | Baseline (2007) |
| ROCm / HIP | Open source, AMD-led | 9 years (2016) |
| SYCL 2020 | Yes, Khronos standard | 14 years (2021) |
| WebGPU, all major browsers | Yes, W3C standard | 18 years (2025) |
What Lock-In Actually Costs in Practice
The cost shows up less in whether a portable alternative technically exists and more in whether the rest of the ecosystem was built to take it seriously. The libraries that made GPU computing usable for non-specialists in the first place, cuDNN, cuBLAS, and the CUDA-first code paths inside PyTorch and TensorFlow, were written years before ROCm, SYCL, or WebGPU had reached anything close to feature parity. Even frameworks that now support multiple backends typically maintain a CUDA path as the default, best-tested route and treat everything else as a secondary target maintained with less engineering attention, which is precisely the dynamic that made HIPIFY’s translate-from-CUDA strategy more practical than asking anyone to write portable code from a blank page.
What actually breaks the lock-in cycle, based on what has worked so far:
- Mechanical translation tools that meet developers inside their existing CUDA codebase, rather than asking for a rewrite
- A large, well-funded single vendor treating portability as a competitive necessity, which is what pushed AMD to build HIP instead of waiting for a committee
- A platform-level forcing function outside any GPU vendor’s control, which is what makes WebGPU different: browsers cannot ship an NVIDIA-only API
What We Have Learned
CUDA’s dominance was never only about NVIDIA building better silicon than everyone else, though it has generally done that too. It was about shipping a complete, proprietary programming platform years before any competitor or standards body had a credible alternative, and then letting an entire decade of libraries, research code, and trained engineers accumulate on top of it before the portable options were even usable. AMD’s ROCm, Khronos’s SYCL, and the W3C’s WebGPU are all real, working answers to the lock-in problem today, but each arrived years to over a decade after CUDA, and the most successful of them, ROCm’s HIP layer, succeeded not by rejecting CUDA’s design but by building a mechanical bridge out of it. That is the clearest evidence available that in GPU programming, portability was never going to win by being vendor-neutral first. It had to win by being compatible with the incumbent first, and neutral second.
