News › linux
By Zayden R., August 24, 2026
Intel engineers have proposed a DRM Fabric for Linux, aiming to create a vendor-neutral, protocol-agnostic infrastructure for GPU and AI accelerator interconnects. This development is significant for those working with diverse hardware ecosystems.
In a move that could streamline GPU and AI accelerator interconnectivity, Intel engineers have proposed a new DRM Fabric for Linux. This proposal aims to establish a vendor-neutral, protocol-agnostic topology infrastructure, which is particularly relevant for scale-up interconnects in diverse hardware environments. For engineers, this means potentially smoother integration across different vendors' GPUs and accelerators, a task that has traditionally posed challenges.
The DRM Fabric proposal outlines a structure where a 'fabric' groups endpoints of a provider-defined interconnect instance. An 'endpoint' here refers to an accelerator attachment with its physical ports, while a 'port' reports lane capability and operational state. A 'peer' indicates the directly adjacent accelerator or switch port, which may be managed by another OS or reside in a different trust domain. This setup records direct adjacency, leaving end-to-end reachability and switch forwarding to the fabric controller.
This proposal matters because it addresses a critical need for a unified approach to managing interconnects without being tied down by vendor-specific implementations. By using Generic Netlink instead of sysfs, the DRM Fabric offers a model that supports multi-object, event-driven interactions, aligning with the YAML-described uAPI discipline introduced to DRM by DRM RAS. The initial patches, numbered 1-6, form a read-only milestone that can be independently merged, while patches 7-12 introduce privileged provisioning for software-defined fabrics.
For those managing complex systems, the ability to create and manage these fabrics from userspace, while leaving hardware programming to the provider, could simplify administrative tasks. The proposal does not attempt to create a network device or manage transport and congestion control, focusing instead on topology and control state representation.
As this is just a proposal, it will be interesting to see how the Linux community responds and what adjustments might be made before any potential integration. Nevertheless, for sysadmins and engineers dealing with multi-vendor environments, this could be a solid improvement over current methods.
The Linux Camp teaches these topics as hands-on labs on real virtual machines, verified as you type.