The i915 Kernel Driver (Part 1): The Linux Graphics Stack Panorama and i915 Overview

The Macro View: A Panorama of the Modern Linux Graphics Stack

On a Linux system, drawing a triangle and displaying it on the screen requires passing through a long and precise pipeline. The modern Linux graphics stack can be broadly divided into two main parts: user space and kernel space.

• User-Space Applications (Apps): Issue drawing commands via standard APIs like OpenGL and Vulkan.
• Mesa3D (User Mode Driver): This is the user-space driver. For Intel, it primarily consists of iris (OpenGL) and anv (Vulkan). It is responsible for translating high-level APIs into machine code that the GPU can understand (Command Buffers).
• DRM (Direct Rendering Manager): The kernel graphics subsystem framework. It provides a unified IOCTL interface for all graphics drivers.
• i915 (Kernel Mode Driver): Our protagonist. It receives Command Buffers from Mesa, schedules the GPU for execution (GT subsystem), allocates video memory (GEM subsystem), and finally sends the rendered frame from memory to the physical display via KMS (Display subsystem).

Mesa handles the "drawing," and i915 handles the "computation" and "display."

Past, Present, and Future: Why is it Still Called i915?

Many beginners are puzzled: today’s Intel GPUs have long since moved to Gen12 (Tiger Lake), Arc (Alchemist), or even more advanced architectures—why is the driver still called i915?

• Origin of the Name: i915 was born around 2004 to support the Intel 915G chipset (which included the GMA 900 integrated graphics, a nostalgic memory from many people's childhoods).
• Historical Baggage and Evolution: Due to a strong tradition of backward compatibility, this driver has been continuously extended. It lived through the era of integrated graphics with Unified Memory Architecture (UMA), and in recent years, in preparation for Intel’s return to the discrete graphics market (DG1, DG2/Arc), it underwent a painful yet brilliant refactoring of its memory model (introducing TTM to support local video memory, or LMEM).
• Future Outlook: Although i915 remains the workhorse today, for entirely new future architectures (such as Lunar Lake), Intel has started developing a streamlined new driver from scratch called xe, shedding the historical baggage from Gen2 to Gen11. However, once you have mastered i915, understanding xe will be a walk in the park.

A Breakdown of the i915 Source Tree

If you jump straight into drivers/gpu/drm/i915/, the hundreds of .c files will absolutely intimidate you. But in reality, looking at its architectural design, the modern i915 source code has a remarkably clear "Golden Triangle" structure.

Let’s examine the three core subdirectories:

Core 1: gem/ (Graphics Execution Manager) — Managing the GPU's Provisions

GEM is the general manager of memory. For a GPU to compute, it needs space to store vertex data, textures, and shader code.

• This is where the fundamental logical unit of video memory, drm_i915_gem_object, is defined.
• It handles memory allocation, deallocation, and cache coherency between the CPU and GPU.
• In modern i915, this directory also contains the interface logic with TTM (Translation Table Manager), used for managing the VRAM on discrete graphics cards.

Core 2: gt/ (Graphics Technology) — Driving the GPU's Engine

The GT layer is responsible for talking to the compute units on the silicon. It is the "foreman" of the driver.

• Contains abstractions for the GPU’s various hardware engines (Render, Video, Blitter, etc.), known as intel_engine_cs.
• Processes execution requests from user space (i915_request).
• Responsible for feeding tasks into the hardware (from early Ringbuffer submissions to modern hardware scheduling based on the GuC microcontroller).
• Handles GPU hangs and hardware resets.

Core 3: display/ — The Magic That Lights Up the Screen

This contains the largest subsystem by code volume (likely accounting for over half of the entire driver). Display is an extremely complex black art involving a myriad of timing and electrical-physical characteristics.

• Implements the KMS (Kernel Mode Setting) model of the DRM framework: CRTC, Plane, Connector, Encoder.
• Handles the negotiation (Link Training) of physical interfaces like HDMI, DisplayPort, and DSI.
• Responsible for Watermark calculations (video memory read buffering levels) and highly complex power and clock management (CDCLK, PLL).

The Hidden Foundation: The Driver's "Roster" and "God Object"

Beyond the three major subsystems, there are two key elements in the root directory that beginners should pay close attention to:

• i915_pci.c and intel_device_info.c (The Roster): This is the driver's "roster." Using thousands of lines of macro definitions, it records the features of every Intel GPU from 2004 to 2024. It is the first "manual" consulted when the driver initializes, telling the driver whether it is facing an ancient integrated chipset or the latest discrete GPU.
• i915_drv.h and struct drm_i915_private (The Source of All Things): i915_drv.h defines the driver’s "God Object" — struct drm_i915_private. If you see variables named i915 or dev_priv in the code, this is what they refer to. It acts as the glue that binds GEM, GT, and Display together. Almost every i915 function takes a pointer to this struct as its first parameter. Once you understand it, you have grabbed this behemoth by the horns.

Coming Up Next:
When your computer boots up and the kernel loads i915.ko within a single second, how does the driver precisely identify that Intel GPU among hundreds of PCI devices and assign it the first MMIO address?