Part 13: Epilogue — The Architectural Evolution from i915 to the Xe Driver

In the previous twelve lectures, we delved from macro architecture down to code details, thoroughly dissecting i915, the massive and complex kernel graphics driver. We saw how it manages memory (GEM/TTM), schedules tasks (Execlists/GuC), lights up displays (KMS), and recovers from disasters (Reset).

However, there is no eternal perfection in software engineering. Over time, business requirements change and hardware architectures evolve, and an existing codebase inevitably accumulates technical debt. In the final lecture of this series, we will step outside the code framework of i915 to discuss its historical baggage and why Intel introduced an entirely new driver in the Linux 6.8 kernel: the Xe driver.

1. Retrospect: The Heavy Historical Baggage of i915

The i915 driver began in 2004. Over a span of 20 years, it has accompanied countless users' computers but has also gradually become an unwieldy behemoth (over 300,000 lines of code). Its "heaviness" is mainly reflected in the following aspects:

1.1 The Long Hardware Support Timeline

Opening i915_pci.c, you will see device IDs ranging from i830 (Gen2) all the way to the latest Meteor Lake and Discrete Graphics (DG2).

• To maintain compatibility with those ancient integrated GPUs that had no hardware scheduler and relied on simple ring buffers for command submission, the code retains numerous legacy execution paths.
• Despite the existence of the firmware-based GuC scheduler, the old Execlists and even older submission mechanisms must still be maintained, making the logic in the gt/ directory intricate and convoluted.

1.2 The Inertia of the Unified Memory Architecture (UMA) Mindset

At i915's inception, Intel GPUs were all integrated, sharing memory with the CPU. This deeply imprinted the mark of UMA on i915's low-level data structures.

• When Intel decided to enter the discrete graphics card market (Arc series) and introduce local memory (LMEM), the i915 team had to painfully cram the veteran TTM (Translation Table Manager) into the originally GEM-based architecture.
• This mid-career integration resulted in code littered with conditional logic (e.g., if (HAS_LMEM(i915))), causing a sharp increase in the maintenance difficulty of the memory management subsystem.

1.3 Complex Synchronization and Display Coupling

• In i915, the display logic (Display/KMS) is highly coupled with the low-level memory management.
• i915's early scheduling design did not fully align with the philosophy of the modern DRM Scheduler, often requiring many complex adaptations when interfacing with modern userspace stacks like Wayland.

2. Breaking the Cocoon: The Design Philosophy of the Xe Driver

Faced with the heavy baggage of i915, Intel decided that when supporting the new generation of GPUs based on the Xe architecture (Tiger Lake/Gen12 and beyond), instead of patching and mending i915, they would write an entirely new driver from scratch — Xe (drivers/gpu/drm/xe).

The core design philosophy of the Xe driver can be summarized as: "Travel light, and do everything for the modern GPU."

2.1 Abandoning History, Focusing on Modern Architectures

The Xe driver only supports GPUs from Tiger Lake and newer architectures (Gen12+).
This means it directly discards the baggage of supporting 15 years of old hardware. Without Ringbuffers or Execlists, the Xe driver, from its very first line of code, completely relies on the GuC (Graphics Microcontroller) for hardware scheduling. This dramatically simplifies the code complexity of the gt/ layer.

2.2 Natively Embracing TTM and the DRM Scheduler

• Pure TTM: The Xe driver no longer has its own custom GEM memory allocator but natively uses the DRM core's TTM framework from the start to manage system memory and discrete memory.
• Standard Scheduler: Xe fully integrates drm_sched (DRM Scheduler). The complex dependency resolution and request ordering logic previously found in i915 is now largely handed off to the kernel's DRM subsystem for unified handling. This not only results in less code for the Xe driver but also allows it to work better with other graphics stacks.

2.3 The User-Mode Queue (VM_BIND) Model

Modern graphics APIs (like Vulkan, Direct3D 12) all adopt an explicit memory management and command queue model.
i915 uses the traditional implicit synchronization (memory is implicitly bound when commands are submitted). In contrast, the Xe driver introduces the modern VM_BIND API:

• Userspace can explicitly bind memory regions to the GPU virtual address space and submit command packets directly to the hardware queues without kernel involvement.
• This 1:1 user/kernel execution queue mapping greatly reduces kernel overhead and enhances the efficiency of CPU command submission for rendering.

2.4 Code Reuse: Clever Display Isolation

While rewriting the low-level memory and scheduling components, Intel did not want to rewrite the extremely large and complex display code (hundreds of thousands of lines handling HDMI/DP/Type-C protocols).
The Xe team made a very ingenious design choice: refactoring i915's Display code into a relatively independent module. Now, when the Xe driver lights up a screen, it actually calls into this stripped-out i915 Display module (you will see Xe source code directly including i915 display header files). This achieves the low-level advantages of a modern architecture while preserving the battle-tested stability of the display output.

3. Conclusion

Over a decade of development has turned i915 into a living textbook of Linux graphics drivers, recording every footprint of GPU technology's journey from weakness to strength. Although the spotlight will gradually shift to Xe, i915 will continue to be maintained for many years, providing stable graphics support to countless older devices.

This series of articles ends here. It is hoped that through the analysis in these 13 lectures, everyone will no longer feel intimidated when facing hundreds of thousands of lines of low-level C code. Although the world of the kernel is profound, as long as you trace the threads of "initialization, memory, scheduling, display," you can always discern its exquisite framework.