Why SPIR-V matters, beyond any one vendor.
Essence generates SPIR-V rather than vendor-specific code. This page explains what SPIR-V is, where it sits in the GPU stack, and why generating it lets one piece of work reach GPUs from AMD, Intel, NVIDIA and other vendors.
Every GPU stack has an intermediate layer. SPIR-V is the open, shared one
Every GPU toolchain compiles work into an intermediate instruction set, and the GPU driver then lowers that to the native instructions of the specific chip. Each vendor has its own route: CUDA for NVIDIA, HIP and ROCm for AMD, oneAPI for Intel. SPIR-V plays the same intermediate role in the Khronos ecosystem, with one decisive difference: it is an open standard that drivers from AMD, Intel, NVIDIA and other vendors consume.
That difference matters most when the instructions are generated rather than written. A person writing a kernel has to pick a language and a vendor. A system that generates the instructions can pick the format that every vendor accepts.
Every vendor stack is its own column, until the layer where SPIR-V sits
The diagram shows how work travels from a programming language down to chip instructions. Follow any column from top to bottom.
- Vendor-native columns. HIP and ROCm lead to AMD instructions, CUDA leads to NVIDIA instructions, and Intel's toolchain leads to Intel and CPU vector instructions. Each is a separate language, compiler and target.
- The Khronos columns converge. OpenCL, OpenGL and Vulkan can all hand their work to a driver as SPIR-V, a binary format that is not tied to any chip.
- The driver finishes the job. SPIR-V is not machine code. Each GPU driver lowers it to the native instruction set of the chip it is running on, including private instruction sets the vendor does not publish.
- DirectX 12 and Metal are separate. They use DXIL and Metal IR as their own intermediate formats. SPIR-V is not their native input.
Essence generates the instructions, so the target format matters
Chameleon turns a statement of intent into Meaning Coordinates, and Morpheus generates the GPU instructions as SPIR-V for the machine that is present. Because the output is SPIR-V, one generation path covers AMD, Intel, NVIDIA and other GPUs that run Vulkan drivers.
- Nothing to author per vendor. The engineer does not write CUDA, HIP or oneAPI code for this path. Our pilot page states that it has no CUDA, ROCm, oneAPI or PyTorch dependency.
- Tuning is generated, not hand-applied. The output is constrained to the target hardware: register limits, driver capabilities and wavefront sizes are respected. The gains reported in the Technical Evaluation Brief come from generating hardware-tuned SPIR-V at runtime, not from hardware upgrades.
- The same intent reaches different chips. Each target receives instructions generated for it, in a format every Vulkan driver accepts.
Hand-authored vendor path versus generated SPIR-V
| Hand-authored vendor path | SPIR-V generated by Essence | |
|---|---|---|
| Source | A kernel in CUDA, HIP or oneAPI, one per vendor | Meaning Coordinates derived from the stated intent |
| Artifact | PTX, GCN or another vendor format | A SPIR-V module generated for each target |
| Hardware tuning | Applied by the engineer, repeated per chip | Generated for the target within its declared limits |
| Moving to another vendor | A new port and a new round of tuning | New generation for that target, same intent |
| Vendor library ecosystem | Available (for example cuDNN and cuBLAS on NVIDIA) | Not provided by this path |
What this does not claim
- Not a fixed-kernel contest. We do not claim SPIR-V is faster than CUDA for a given hand-tuned kernel on fixed hardware. Fixed benchmarks measure fixed artifacts, and Essence generates a different artifact for each machine. See the Technical Evaluation Brief for what was measured and how.
- Vulkan-capable GPUs. The SPIR-V path reaches AMD, Intel, NVIDIA and other GPUs through their Vulkan drivers. DirectX 12 and Metal take their own intermediate formats, so they are outside what this page claims. Measurements so far are on AMD and NVIDIA GPUs. The same format reaches other vendors, but their GPUs are not part of the measured set.
- The driver still matters. The final lowering to native code is performed by the vendor's driver, so driver quality and version affect results.
- No SPIR-V export yet. Chameleon generates SPIR-V at runtime. Exporting it as a file for external pipelines is not available. Runtime Qcode is generated, executed and discarded within a session. See Qcode and Morpheus.
- Libraries are not replaced. Vendor math and deep-learning libraries remain what they are. This path covers instructions that Chameleon generates.
What can be checked today
SPIR-V file export is not available yet, so a generated module cannot be taken out and opened with a disassembler today. The result can still be checked by its behavior.
- Run the evaluation build on your own workload, on the AMD, Intel, NVIDIA or other Vulkan-capable GPU you already own.
- Compare the result against your own frozen build on the same machine, using success criteria fixed in advance.
- Check that the result holds when the hardware or conditions change, without rewriting anything.
- When SPIR-V export becomes available, the open SPIRV-Tools suite (validator spirv-val, disassembler spirv-dis) is the natural way to inspect a module. Verify current usage in the Khronos documentation.
SPIR-V is the open, cross-vendor layer that AMD, Intel, NVIDIA and other Vulkan drivers accept, while CUDA, HIP and oneAPI each lead to one vendor. Because Essence generates instructions instead of asking an engineer to write them, it can target that shared layer and tune the output for each machine, without a separate port per vendor.