Overview of a Modern DRM Driver

### Overview In this presentation, Matt from Imagination Technologies details the development of an upstream open-source Linux Direct Rendering Manager (DRM) driver stack for PowerVR GPUs. Developed over four years, the driver stack focuses on a modern Vulkan-first design, targeting chips like the AXE-1-16M integrated on Texas Instruments AM625 development boards. The team utilized these boards to pass the Vulkan Conformance Test Suite (CTS) and reach official Vulkan 1.0 conformance, while relying on Mesa's Zink layer to expose OpenGL compatibility on top of Vulkan.

### Key Topics The talk centers on leveraging and adapting modern DRM subsystem shared frameworks rather than reinventing custom solutions, highlighting two key kernel components: - **The DRM Scheduler**: Originally originating in the AMDGPU driver and moved to common code, it coordinates execution queues and handles subtle DMA fence semantics. - **GPUVM**: The GPU virtual address manager initiated by Danilo Krummrich and Dave Airlie (Red Hat) to provide user-space manageable GPU address spaces for Vulkan and modern VM bind workflows. - **Firmware-Based Scheduling Challenges**: Reconciling kernel-level scheduling abstractions with on-chip GPU firmware schedulers. - **Upstream Collaboration**: Navigating the moving target of bleeding-edge kernel patchsets and the benefits of shared code across vendors.

### Technical Details PowerVR GPUs incorporate dedicated firmware that schedules tasks directly on the GPU to minimize latency and CPU overhead. However, the driver still needs the kernel DRM scheduler to enforce DMA fence dependencies. Initial proposals (such as Matt Brost's `DRM_SCHED_POLICY_SINGLE_ENTITY` RFC for Intel's Xe driver) introduced special-cased single-entity scheduling. The ultimate design, proposed by Luben Tuikov (AMD), allowed drivers to declare custom priority levels and define how many run queues they require. By declaring only one priority level and one entity per scheduler, the PowerVR driver guarantees strictly ordered job submissions without conflicting with firmware scheduling.

For memory management, the driver adopted GPUVM to handle virtual address allocation, GEM buffer mapping, and complex operations such as sparse binding and address splitting for partial mappings/unmappings. Although tracking changing patch revisions across 7–8 iterations introduced integration overhead, collaborating directly with maintainers ensured edge cases were resolved within upstream common libraries rather than out-of-tree forks.

### Takeaways Matt emphasizes that maintaining out-of-tree, duplicated driver components causes fragmentation and maintenance burdens. Collaborating on common DRM kernel infrastructure enables multiple hardware vendors (including Intel, AMD, ARM, and Imagination) to test shared code across distinct architectures. Furthermore, modern GPU architecture increasingly moves execution scheduling into firmware, while CPU-controlled MMUs and page tables maintain hardware isolation boundaries.