What it takes to make a second vendor first-class

2026-07-25 · Caldrix Engineering

"Also supports AMD" is one of the cheapest claims in this industry. It usually means a compatibility layer translates the CUDA-shaped calls, the kernels compile, the tests go green, and performance lands wherever it lands. Nobody promised it would run well, and the benchmark that would have said otherwise only ever ran on the first vendor.

Making a second vendor genuinely first-class is a different exercise, and most of the work is not in the kernels. It is in refusing to let the first vendor's assumptions leak into the IR. A surprising number are load-bearing: the warp size, the layout of the kernel argument buffer, how scratch memory is addressed, what the code-object metadata must say for a launch to be legal, which runtime version the host happens to have. Each is invisible with a single target, and each becomes a launch that fails with a numeric error code the moment you have two.

Our rule for the AMD work has been that the hardware model gets extended, never special-cased. A different argument layout or an extra linker step becomes a parameter of the target description, with a probe that establishes its value on the machine — not an if amd branch in the lowering. Branches accumulate; parameters compose. The third vendor is only cheap if the second was done as a generalization instead of a fork.

What keeps this honest is refusing to call anything supported until it has executed on real silicon. Code that assembles, links and passes an offline verifier has demonstrated exactly that. Until a kernel has run on the device and produced the values we expected, the honest status is "built, not executed" — and that is what our tracking says, because the alternative is a support matrix that is really a wish list.

Compilers are how you get out of the porting business, but only if you build them as if the second target were always going to arrive.