Hardware Accelerators

Relevant source files

The following files were used as context for generating this wiki page:

• Documentation/accel/introduction.rst
• Documentation/gpu/introduction.rst
• Documentation/gpu/xe/xe_firmware.rst
• Documentation/arch/arm64/arm-acpi.rst
• Documentation/kernel-hacking/hacking.rst

The Linux compute accelerators subsystem exposes compute hardware to user-space through a common interface. These devices include stand-alone ASICs or IP blocks within a System on Chip (SoC) or Graphics Processing Unit (GPU). While primarily targeting Machine-Learning (ML) and Deep-Learning (DL) computations, the subsystem supports various accelerator types.
Sources: Documentation/accel/introduction.rst:4-11

Subsystem Architecture

The accelerator subsystem integrates with the Direct Rendering Manager (DRM) subsystem. It utilizes DRM core code and functionality because accelerators often share characteristics with GPUs or exist as IP blocks within them. This integration allows the subsystem to leverage existing memory management, interrupt handling, and DMA infrastructures.
Sources: Documentation/accel/introduction.rst:32-38, Documentation/gpu/introduction.rst:7-13

Differentiation from GPUs

To prevent standard graphics stacks from treating accelerators as GPUs, the subsystem uses distinct identification markers:

• Major Number: The subsystem uses dedicated major number 261.
• Device Files: Character files reside in /dev/accel/accel*.
• Sysfs: Class information appears in /sys/class/accel/accel*/.
• Debugfs: Debugging nodes are located in /sys/kernel/debug/accel/*/.
  Sources: Documentation/accel/introduction.rst:45-53

Component Relationship

The following diagram shows the relationship between the Accel subsystem, DRM, and hardware:

Device Categories

Hardware accelerators fall into three primary functional categories based on their deployment and computational characteristics.
Sources: Documentation/accel/introduction.rst:13-14

Category	Description	Key Features
Edge AI	Inference at edge devices or embedded ASICs.	Register-based config, optional DMA.
Inference Data-Center	Multi-user devices in servers.	On-board DRAM, DMA engines, MMU, SR-IOV.
Training Data-Center	High-power cards for model training.	HBM memory, high scale-up/out connectivity.
Sources: Documentation/accel/introduction.rst:16-30

Driver Implementation

To expose a device via the accelerator subsystem, a driver must implement specific configurations within the DRM framework.

Required Features and Configuration

1. Feature Flags: The driver must include DRIVER_COMPUTE_ACCEL in the drm_driver struct. This flag is mutually exclusive with DRIVER_RENDER and DRIVER_MODESET.
2. File Operations: The driver must set the open callback to accel_open(). The DEFINE_DRM_ACCEL_FOPS macro provides a standard structure for these operations.
3. Kernel Config: The kernel must be built with CONFIG_DRM_ACCEL enabled.
   Sources: Documentation/accel/introduction.rst:60-75

Hardware Management

Accelerators often require complex firmware management and power control. Drivers use the ACPI framework on supported architectures (like ARM64) to manage power resources via _PS0 (Full On) and _PS3 (Off) methods.
Sources: Documentation/arch/arm64/arm-acpi.rst:325-335, Documentation/gpu/xe/xe_firmware.rst:7-15

Summary

Hardware Accelerators in Linux provide a standardized path for specialized compute hardware to interact with user-space applications. By building upon the DRM subsystem, the accel layer maintains architectural consistency while providing the unique naming and numbering required for modern AI and data-center workloads.
Sources: Documentation/accel/introduction.rst:4-11, Documentation/accel/introduction.rst:43-48