London-based Spectral Compute is developing a toolchain called "SCALE" that compiles NVIDIA CUDA source code directly for AMD GPUs. In the company's latest measurements, it outperformed the HIP port by an average of 6.19x on an AMD Instinct MI300X. But this figure does not mean AMD GPUs beat NVIDIA GPUs by that margin. It measures the difference, on the same AMD-made GPU, between running CUDA source through SCALE versus going through AMD's own porting path.
SCALE's goal is not to abandon CUDA, but to decouple the tie between CUDA and NVIDIA GPUs at the compiler level. If achieved, this would let organizations keep years of accumulated CUDA code intact and simply recompile it for whichever GPU they can procure. However, CUDA's strength extends well beyond language specification. Frameworks are layered atop runtime and numerical libraries, and NVIDIA-specific low-level code often creeps in, so getting the compiler to run is not the same as completing a port.
What Does the 6.19x Figure Actually Compare?
The measurements Spectral Compute published in May 2026 ran the Rodinia benchmark suite—aimed at scientific and technical computing—on an AMD Instinct MI300X. The comparison target was HIP running on ROCm 7.2.0, and SCALE was faster on 10 of 14 workloads. The average speedup was reportedly 6.19x, with a maximum of 33.8x.
The measurement methodology was also disclosed. Each benchmark was run a total of 150 times, split across 5 independent rounds, with timing starting after initialization and warm-up. Time spent purely on the CPU side—such as file I/O or host memory allocation—was excluded. For the representative value, the minimum recorded execution time was used rather than the median.
Two caveats apply here. First, because the maximum value of 33.8x pulls the average upward, the 6.19x figure should not be treated as a typical improvement rate for applications in general. On 4 of the workloads, SCALE did not outperform HIP. Second, these results come from self-reported measurements by the developer, and no third-party reproduction under the same conditions has been confirmed. While the minimum value is suited to observing the lower bound of steady-state execution a compiler can reach, it does not reveal the median or variance that matter in real-world operation.
As a point of contrast, in measurements comparing against NVIDIA's nvcc under CUDA 13 on an NVIDIA B300, SCALE was at most 9% faster, while average performance came in at 0.98x. Interpreting SCALE's value as "a compiler that's always faster" would be a misreading. While it's clear that a significant gap currently exists on the AMD side, the published results alone don't allow us to isolate the individual factors driving that speedup.
Not Translation, But CUDA to Native Instructions
AMD's HIPIFY is a tool for migrating CUDA source code to HIP C++. It converts API names and language constructs, after which the code is built using ROCm's compilers and libraries. For large codebases, this typically requires manual fixes after automated conversion, plus ongoing work to track divergence between the CUDA and HIP versions.
SCALE takes a different path. It presents a compatible front end that appears to the build system as NVIDIA's nvcc, and it parses the CUDA dialect that nvcc accepts. For AMD targets, it uses LLVM's AMDGPU backend to generate native instructions, connecting to its own reimplemented CUDA Runtime, Driver, and Math APIs. For CUDA-X APIs such as cuBLAS, it calls the corresponding ROCm libraries through wrappers. For NVIDIA targets, only the compiler is swapped out, while the runtime libraries remain NVIDIA's own.
This design allows switching target GPUs without major changes to existing build configurations. But the word "drop-in" is not a guarantee that every CUDA program will run unmodified. SCALE itself maintains a list of unimplemented APIs and explicitly states that development is ongoing. Compatibility isn't settled by marketing language—it's confirmed only once each application has been verified for compilation, numerical agreement, and performance.
Extracting AMD-Specific Instructions From CUDA Code
As one example of how SCALE improves performance, Spectral Compute points to compiler optimizations that target AMD-specific hardware. That said, the company has not broken down the overall Rodinia speed differences by individual optimization, so it's unclear how much DPP contributed to the average 6.19x figure. The specific example given involves "shuffle" operations, which exchange values between threads within a GPU. The typical LLVM path for AMD targets uses ds_bpermute, which supports a wide range of permutations. It's flexible, but costly, since it routes through the shared-memory path.
AMD GPUs offer Data-Parallel Primitives (DPP), which handle certain data-exchange patterns entirely within registers. SCALE recognizes CUDA shuffle and reduction patterns and, when conditions allow, lowers them to DPP. In some cases it can even fuse the exchange and addition into a single instruction, requiring fewer instructions than the general-purpose path. In effect, it draws out AMD-side capabilities that don't exist on NVIDIA, starting from abstract processing written in CUDA.
This nicely illustrates the difference between a porting tool and an optimizing compiler. Simply changing the source notation from CUDA to HIP doesn't automatically guarantee optimal selection of target-specific instructions. SCALE keeps CUDA as a common input language, while performing different optimizations underneath for each GPU. It's the same idea as compiling identical C++ for Intel or Arm on the CPU side—brought over to the GPU.
That said, hardware differences can't be erased by the compiler alone. NVIDIA's warp is typically 32 threads, while some AMD products use a 64-thread wavefront. If CUDA code or inline PTX assumes a 32-bit lane mask, SCALE may be able to issue a warning, but it may not always be able to automatically fix the underlying intent. "Accepting the same source" and "preserving the same parallel execution semantics" are two separate challenges.
The Real Battleground for CUDA Compatibility Is Libraries
CUDA applications don't consist solely of a compiler and runtime. Frameworks sit on top of purpose-built libraries—cuDNN and cuBLASLt for AI, cuSOLVER for scientific computing, and so on. For SCALE to run these on AMD, it must faithfully reproduce CUDA API behavior while correctly mapping it onto the corresponding ROCm-side libraries.
The publicly available SCALE 1.7.1 verification table shows both how far things have come and how much distance remains. Rodinia, llama.cpp, FFmpeg, and others have successfully verified across multiple AMD/NVIDIA targets. In contrast, PyTorch, vLLM, cuML, and others show failed verification on the listed targets. Even the PyTorch support advertised on the official site is a pre-release available only to those who request it—not yet a generally available version capable of replacing an entire AI stack.
The abundance of failures in the verification table isn't evidence that the design doesn't work. It reflects the fact that not-yet-supported projects also get added early to the public repository. Compatibility isn't a single pass/fail determination. Even if a kernel compiles, the application won't run if a required CUDA-X API is missing. And even if it does run, changes in numerical precision or performance mean re-verification is needed before production deployment.
Look at Verification Cost Before Price
SCALE is free for research, education, and non-profit use, but its public license does not permit commercial use. Organizations using it for for-profit business need a paid contract, and pricing is not disclosed. Companies must therefore weigh adoption costs alongside GPU hourly rates—estimating license fees against the engineering hours saved by avoiding a port, while also factoring in the procurement value of being able to choose among multiple vendors and the time needed for re-verification.
According to HPCwire, Spectral Compute has been developing compilers since its founding in 2018 and raised $6 million in 2025. At the time of reporting, it had roughly 30 employees. That's a small organization to carry the weight of implementing compatibility for the massive CUDA ecosystem—but conversely, it also illustrates that the difficulty of breaking dependence on CUDA lies less in silicon design and more in the painstaking work of software implementation.
Whether SCALE can crack open CUDA's moat depends less on headline figures like the 33.8x maximum and more on how many real applications it can run unmodified, with reproducible performance. The evidence to watch for is an official PyTorch release, the range of successes in the public verification table, and third-party reproduction of the Rodinia measurements. Once those three things are in place, it will start to become a credible option for considering AMD while keeping CUDA code intact.