Based on the August 13, 2026 B70/Linux feasibility investigation and a later preserved alpha checkpoint. That checkpoint is not independently dated here. No new kernels were compiled or executed for this guide. Compatibility is narrow and workload-specific.
Find your first porting route.
Start with the dependency that prevents your project from running. Repeat for each blocker.
Try native PyTorch XPU
Audit device selection, tensor creation, precision and synchronization. Check each operation against an explicit reference; changing a device string alone does not establish compatibility.
Read the native XPU route →Inventory the assumption
“Requires CUDA” can describe several different problems. A Python application may simply hardcode a device. A dependency may call a vendor library. A source extension may use ordinary kernels. Another package may ship only NVIDIA binaries or rely on inline PTX.
Record which of these is actually present before choosing a route. Follow imports and optional feature flags into the dependency that blocks execution. A successful top-level package installation says little about which implementation will run.
For each blocker, keep the package version or source commit, file and line, expected operation, input shapes and dtypes, and a reference output. The interactive selector above is an entry point to that investigation, not a compatibility certification.
Native XPU
Start here when the workload is expressed in PyTorch operations with an available XPU implementation. Audit tensor construction, device selection, mixed precision, random-number behavior, synchronization, and extension imports. Find the code path actually selected at runtime.
A global replacement of a CUDA device string can miss a dependency that still imports a CUDA-only extension. It can also make a test pass through a fallback path. Verify the output device and the numerical result explicitly.
In the preserved feasibility work, native XPU acted as the framework authority while selected operations used other implementations. That architecture kept tensor ownership explicit rather than pretending every CUDA interface had acquired identical behavior.
Native operations
When a CUDA dependency implements a recognizable operation, consider a native equivalent. The feasibility work explored native attention and oneMKL GEMM substitutions. The useful question was whether the replacement preserved the caller’s contract.
Compare the details that affect correctness: masking, causal behavior, layout, dtype, accumulation, shape edge cases, error handling, and stream ordering. For training, forward equivalence alone is insufficient; gradients and update paths need their own evidence.
Establish a reference on representative and awkward shapes. Time the operation only after that check passes, and distinguish setup cost from repeated execution. An isolated matrix multiply result is not evidence that a full CUDA library has been replaced.
Source translation
chipStar provides a compiler/runtime route from HIP/CUDA toward SPIR-V through OpenCL or Level Zero. It is a candidate for suitable source, with explicit coverage limits. Source availability is the beginning of the porting task.
The B70 investigation found working ordinary kernels alongside required build changes, pointer-format handling, and source-level adaptations. It also found that cross-runtime tensor access depended on sharing the right allocation context and ordering work correctly.
Do not infer safe interoperability merely because two APIs accept a pointer. Check ownership, lifetime, context identity, producer/consumer ordering, and failure cleanup. A test that accidentally synchronizes the entire device can hide an event-ordering problem while distorting performance.
A sensible sequence is: compile one small operation; prove where it executes; compare its output; test repeated calls; then integrate it into the real application. Preserve a failing case when the next layer exposes an incompatibility.
Hard boundaries
NVIDIA-specific binaries do not become portable source when the surrounding Python package is installed. Inline PTX and architecture-tuned CUTLASS paths can require an alternative implementation rather than mechanical translation.
In the retained FlashAttention investigation, a reduced PTX case exposed a particularly important failure: the compiler could report success while warning about broken output, followed by failure in a later SPIR-V transformation. Build success was therefore not an execution guarantee.
Treat warnings, unsupported operations, and missing declarations as part of the compatibility result. Fail explicitly when the requested path cannot be supported; do not let an unvalidated fallback silently inherit the original performance or correctness claim.
The Mamba checkpoint
The preserved alpha checkpoint describes a clean-checkout Mamba-130M recipe executing inference on each B70 with translated causal-convolution forward work and explicit native substitutions. Its warmed hybrid/native runtime ratios were 1.771 and 1.905, measured in short three-sample runs. A ratio above one means the hybrid took longer than the native comparison.
This is a narrow outcome. The recipe still depended on a development source tree and a built interoperability bridge. Backward, cache/update, channel-last, fused selective scan, and Mamba-3 remained unsupported or unverified. It does not establish full Mamba support, a general CUDA replacement, or a packaged installation product.
Those findings come from an internal preserved status record, SHA-256 recorded in the project’s private evidence manifest. Public raw harness evidence for this checkpoint is not available on this site. Treat the figures as reported experimental observations, not independently reproducible benchmark entries.
Define success before optimizing
A useful porting report identifies the exact operation, project revision, environment, execution device, adapted components, reference comparison, repeated-run behavior, and unsupported surface area.
For inference, test realistic input shapes and sustained output quality. For training, add gradient and optimizer validation. For asynchronous integration, test the dependency itself rather than only a final value that a synchronization barrier might make correct.
The strongest practical lesson from this work is to choose the implementation per operation: native XPU where appropriate, native library substitutions where they preserve semantics, translation for suitable source, and an explicit boundary where NVIDIA-specific assumptions remain. See the project notes for what is public and what remains experimental.