OptiX is not a fourth compute API sitting beside CUDA, OpenCL and SYCL. It is an NVIDIA ray-tracing framework built on top of CUDA, using the same device memory model and the same compilation toolchain, and adding a scheduler plus RT-core-backed traversal and intersection primitives. Comparing the two as rival APIs on a benchmark chart is a category error.
Is OptiX a separate compute API or a layer on CUDA?
A layer. OptiX programs compile through the same NVIDIA toolchain that CUDA kernels use, and they address the same device allocations — which means you can run plain CUDA kernels and OptiX launches over one set of buffers without duplicating memory management. What OptiX adds on top is an acceleration-structure build-and-refit path, a shader binding table, ray payload plumbing, and a scheduler that feeds the RT cores.
That framing changes the question. You are not picking a vendor API; you are deciding which layer owns the parallel decomposition. Write CUDA when you own that decomposition. Reach for OptiX when the workload is ray-based and you would rather use NVIDIA’s acceleration structure and traversal than maintain your own bounding volume hierarchy.
Where the two diverge
The divergence point is narrow and testable: is the dominant cost in your kernel ray traversal against a scene structure? If it is, hand-written CUDA traversal rarely beats RT-core traversal. If it is not, OptiX layers a programming model onto a kernel that gains nothing from it.
| Choose CUDA | Choose OptiX | |
|---|---|---|
| Dominant kernel cost | Arithmetic, reductions, custom data movement | Ray traversal against a scene BVH |
| Who owns the decomposition | You do | The framework’s scheduler does |
| Acceleration structure | You build and refit your own BVH | NVIDIA builds and refits it |
| RT cores | Not reachable from a general CUDA kernel | Reached through traversal primitives |
| Added plumbing | None | Pipeline, SBT, ray payloads |
| Portability cost | NVIDIA-only | NVIDIA-only, plus a second layer of it |
The last row matters more than teams expect. OptiX inherits CUDA’s NVIDIA-only constraint and adds its own on top, so the lock-in cost is strictly higher — not equal. If portable ray tracing across AMD or Intel silicon is a live requirement, that requirement belongs in the decision before the throughput numbers do. We treat this the same way we treat any other API-selection question in GPU performance and porting work: name the constraint that survives a hardware change, then optimise inside it.t.t.
What to measure
The metrics that decide the layering are traversal throughput per frame and rays per second at a fixed image-quality target, plus acceleration-structure rebuild time for dynamic scenes. Rebuild time is the one most often left out, and it is the one that sinks animated or simulated scenes where geometry changes every frame.
In our experience the avoided cost is as real as the throughput gain. A team that correctly concludes its kernel is not ray-dominated saves itself an OptiX pipeline, a shader binding table and payload plumbing it would then have to maintain — and a team that concludes it is ray-dominated stops maintaining a hand-rolled BVH build-and-refit path it never wanted to own.
If your renderer or simulation pass is mid-way through its own traversal implementation, the question worth answering first is not which API is faster, but whether the frame budget is being spent on traversal at all.
