GPU execution paths and their support limits
Understand current CUDA, ROCm, Vulkan and wgpu implementations, the absence of OpenCL, and the limits of historical NablaTensor comparisons.
An old GPU benchmark can describe real work without describing a current release. The pre-split NablaTensor articles compare CUDA, ROCm, Vulkan and OpenCL on recorded scalar pricing tapes. Current jax4j has a different set of modules, and wgpu implements a different interface.
Follow the compiler, then check the adapter
| Path | Kernel compilation | Current status |
|---|---|---|
| CUDA | CUDA source compiled by NVRTC | Optional tensor and scalar replay module; 0.2.1 execution not revalidated |
| ROCm / HIP | Runtime kernels compiled by HIPRTC | Optional tensor and scalar replay module; hardware unverified |
| Vulkan | Generated shaders compiled to SPIR-V | Tensor and scalar implementations; 0.2.1 hardware validation |
| wgpu-native | WGSL and native shader lowering through wgpu-native | Tensor implementation; 0.2.1 hardware validation; no scalar replay adapter |
| OpenCL | Historical NablaTensor code generated OpenCL C | No current jax4j engine module or provider |
ROCm is implemented: the current source contains the HIP runtime bindings, tensor kernels, scalar replay compiler and service registrations. Its published JAR does not establish correctness on your AMD GPU. Hardware validation remains a gap in the 0.2.1 release evidence. CUDA was tested in 0.2.0, but the namespace migration release could not rerun those hardware checks.
All these GPU runtimes need compatible native libraries and drivers. Java's
--enable-native-access=ALL-UNNAMED enables the FFM calls; it does not install a
driver or add missing device capabilities. Requesting an engine explicitly
should fail when unavailable. Use the support matrix and
provider discovery lesson before
choosing a deployment target.
A tensor device is not a scalar pricing adapter
In current jax4j, Device.wgpu() can place a tensor on the native wgpu backend.
There is no corresponding scalar AadEngine service provider. A command that
switches a recorded Monte Carlo tape to .on("wgpu") is therefore not justified
by the tensor backend's availability. The Quant 0.4.0 release also records two
scalar checks skipped on wgpu for this reason.
Quant 0.4.0 depends on jax4j 0.1.0. jax4j 0.2.1 uses the new
com.nablatensor.jax4j namespace, so updating the version alone is not enough
to migrate a Quant application. Keep the finance release's dependency contract
separate from current tensor examples.
Precision and performance need their own evidence
The historical scalar Vulkan implementation uses FP32. Native wgpu tensor kernels also have documented dtype and operation limits. CUDA and HIP scalar paths include FP32 and FP64 code, but that does not promise every tensor operation supports both. Inspect the API and operation you actually use.
A timing from a Radeon iGPU and one from an NVIDIA card on another machine cannot rank the APIs independently of hardware. Nor do old timings certify current code after an API migration. The old diagram is retained for context:
The original benchmark article needs a release and provenance update before serving as a current installation guide. Its numbers have not been rerun in this documentation audit.
Run a CPU reference in this browser
This cell uses the legacy TeaVM finance runtime and its CPU interpreter. It does not run the native GPU paths in the table. The newer jax4j notebooks have a separate browser WebGPU bridge for supported eager tensor operations; that bridge rejects generated JIT and device-region kernels. Its capabilities are not those of native wgpu, ROCm, CUDA or Vulkan.
Continue with basket options for correlated underlyings, and keep the execution environment explicit when comparing results.