Skip to content
Tensormorph
Developer Platform
Compute backend API

Compute Backend API

Tensormorph's five built-in backends - CPU, WebGPU, CUDA, ROCm, and Metal (see GPU Backend Compatibility) - aren't a closed set. An AcceleratorBackendPlugin is how support for an additional accelerator gets added without changing Tensormorph's core scheduling logic.

What a backend plugin provides

The scheduler that places operations by capability and cost (see How backend selection works) doesn't know about specific hardware - it knows about backends that can each answer "can you do this operation, and at what estimated cost." An AcceleratorBackendPlugin implements that same contract for a new accelerator:

  • Which operations it supports, and at what capability level.
  • A cost estimate for a given operation on that backend, so the scheduler can compare it fairly against the built-in backends.
  • The actual execution path for a supported operation.

Never hardware-name branching

⚠️

A backend plugin should never require core Tensormorph code to special-case its hardware by name. Adding an accelerator means implementing the same capability-and-cost contract every other backend implements - if adding your backend required editing Tensormorph's scheduler, something about the plugin contract is being bypassed rather than used.

This is the same principle GPU Backend Compatibility describes for the built-in backends, extended to third-party ones: the scheduler's job is choosing among backends that all speak the same contract, not knowing about any of them individually.

Partial support is expected

A new backend doesn't need to support every operation Tensormorph can perform on day one - where it lacks a specific capability (a particular quantized kernel, for instance), the scheduler falls back to a backend that does support it, the same way built-in backends already handle uneven kernel coverage. Declaring narrower support honestly is preferable to claiming broad support and failing at runtime.

Related resources