Backends

Run TorchCTS in the Python environment used to build and test the backend. The focused suite can be used during implementation, in backend CI, and for release validation on target hardware.

Install Build Vs Runtime Backend

The installer chooses a PyTorch wheel family. torchcts run --device selects the backend under test.

Supports PyTorch 2.7.0-2.12.1. Backend validation still comes from running your backend.

In-Tree Backends

CPU

Runtime device: cpu.

Use CPU for harness checks, local development, CPU references, and CPU-build backend packs.

CUDA

Runtime device: cuda.

Use a CUDA PyTorch wheel and run with --device cuda.

ROCm / HIP

Runtime device: .

PyTorch ROCm builds expose HIP devices through the CUDA namespace. Use --device cuda and backend-pack gates such as rocm when collecting ROCm evidence.

MPS

Runtime device: mps.

Use the macOS PyTorch build with MPS support. MPS crash isolation rules are subprocess isolation only; they do not forgive crashes.

Do not use --validation --device mps as MPS backend evidence. Validation mode forces CPU.

XPU

Runtime device: xpu.

Use an Intel XPU-capable PyTorch build and run with --device xpu.

Backend-Pack Gates

Some backend evidence targets a build family, not torch.device(...).type.

ROCm is the common example: PyTorch reports the runtime device through cuda, but the evidence gate is rocm.

Canonical backend evidence records live under evidence/backends/. They identify the device, backend gate, PyTorch version, selected dispatcher surfaces, oracle or property result, command intent, and run status without storing host identity or absolute local paths.

torchcts coverage collect-backend-evidence --store evidence/backends --device cuda --backend-gate cuda+rocm
torchcts coverage collect-backend-evidence --store evidence/backends --device cuda --backend-gate cuda --run-pending-candidates --require-oracle-results --fail-on-oracle-failure

Runtime Selection

torchcts run --device cuda --level 4
torchcts run --device mps --level 4
torchcts run --device xpu --level 4
torchcts run --device my_privateuse1_backend --level 4

PrivateUse1 Backends

PrivateUse1 lets an out-of-tree backend register a custom PyTorch device without taking a permanent in-tree dispatch key.

This catalog is an engineering reference, not a certification list or endorsement. It lists PrivateUse1-style integrations that backend engineers can study or test.

PrivateUse1 projects move independently. Check each backend's current PyTorch support before treating it as a TorchCTS validation target.

manifest = {
    "manifest_version": 1,
    "device_name": "my_backend",
    "backend_import": "my_backend_package",
    "supported_dtypes": {
        torch.float32: True,
    },
    "semantic_level": 2,
    "capabilities": {
        "inference": True,
        "training": False,
        "rng": False,
        "device_api": True,
        "multi_device": False,
    },
}

Ascend NPU (torch_npu / Huawei Ascend)

https://github.com/ascend/pytorch

Package/import: torch_npu.

Typical device name: npu.

Ascend Extension for PyTorch adapts Huawei Ascend NPUs to PyTorch through torch_npu and CANN. It has version-matched branches for PyTorch and CANN releases, NPU APIs, distributed support, AMP-related support, and production-oriented backend integration.

TorchCTS note: use backend_import = "torch_npu" and device_name = "npu" when validating an installed Ascend environment.

torch-directml (Microsoft DirectML)

https://learn.microsoft.com/en-us/windows/ai/directml/pytorch-windows

Package/import: torch_directml.

Typical device handle: torch_directml.device().

torch-directml maps Microsoft DirectML to PyTorch on Windows hardware. Microsoft documents it as a PrivateUse1-backed package and exposes a DML device helper.

TorchCTS note: Microsoft's current docs say torch-directml supports up to PyTorch 2.3.1. TorchCTS 0.4.1 validates PyTorch 2.7.0-2.12.1, so list DirectML as an ecosystem example unless a compatible DirectML/PyTorch build is available.

torch-webgpu

https://github.com/jmaczan/torch-webgpu

Typical device name: webgpu.

torch-webgpu is an out-of-tree PyTorch backend and compiler path targeting WebGPU through Dawn and WGSL. It focuses on portable GPU execution and torch.compile-oriented workflows.

TorchCTS note: treat it as an active backend project. Validate the installed package and supported PyTorch version before claiming TorchCTS support.

pytorch_dlprim / pytorch_ocl

https://github.com/artyom-beilis/pytorch_dlprim

Package/import: pytorch_ocl.

Typical device name: ocl.

pytorch_dlprim is an OpenCL backend using DLPrimitives. It supports OpenCL-compatible GPUs across vendors and documents use through the ocl device.

TorchCTS note: use backend_import = "pytorch_ocl" and device_name = "ocl" when the installed wheel matches the PyTorch version under test.

OpenReg (torch_openreg)

https://pytorch.org/blog/openreg-a-self-contained-pytorch-accelerator-simulator/

Package/import: torch_openreg.

Typical device name: openreg.

OpenReg is PyTorch's reference PrivateUse1 accelerator simulator. It is designed for backend integration work, not as a production accelerator.

TorchCTS note: OpenReg helps validate backend mechanics such as device registration, operator registration, streams, events, guards, AMP plumbing, and runtime behavior.

CI Guidance

In non-interactive jobs, always pass --device. Upload results/ even when the job fails. The failed run is usually the evidence you need.

Use focused commands for pull-request feedback and broader semantic-level runs for scheduled or release validation. Upload the results directory when a job fails so the failure remains actionable.