Documentation/gpu/amdgpu/driver-core.rst
Source file repositories/reference/linux-study-clean/Documentation/gpu/amdgpu/driver-core.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/gpu/amdgpu/driver-core.rst- Extension
.rst- Size
- 10366 bytes
- Lines
- 245
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
============================
Core Driver Infrastructure
============================
GPU Hardware Structure
======================
Each ASIC is a collection of hardware blocks. We refer to them as
"IPs" (Intellectual Property blocks). Each IP encapsulates certain
functionality. IPs are versioned and can also be mixed and matched.
E.g., you might have two different ASICs that both have System DMA (SDMA) 5.x IPs.
The driver is arranged by IPs. There are driver components to handle
the initialization and operation of each IP. There are also a bunch
of smaller IPs that don't really need much if any driver interaction.
Those end up getting lumped into the common stuff in the soc files.
The soc files (e.g., vi.c, soc15.c nv.c) contain code for aspects of
the SoC itself rather than specific IPs. E.g., things like GPU resets
and register access functions are SoC dependent.
An APU contains more than just CPU and GPU, it also contains all of
the platform stuff (audio, usb, gpio, etc.). Also, a lot of
components are shared between the CPU, platform, and the GPU (e.g.,
SMU, PSP, etc.). Specific components (CPU, GPU, etc.) usually have
their interface to interact with those common components. For things
like S0i3 there is a ton of coordination required across all the
components, but that is probably a bit beyond the scope of this
section.
With respect to the GPU, we have the following major IPs:
GMC (Graphics Memory Controller)
This was a dedicated IP on older pre-vega chips, but has since
become somewhat decentralized on vega and newer chips. They now
have dedicated memory hubs for specific IPs or groups of IPs. We
still treat it as a single component in the driver however since
the programming model is still pretty similar. This is how the
different IPs on the GPU get the memory (VRAM or system memory).
It also provides the support for per process GPU virtual address
spaces.
IH (Interrupt Handler)
This is the interrupt controller on the GPU. All of the IPs feed
their interrupts into this IP and it aggregates them into a set of
ring buffers that the driver can parse to handle interrupts from
different IPs.
PSP (Platform Security Processor)
This handles security policy for the SoC and executes trusted
applications, and validates and loads firmwares for other blocks.
SMU (System Management Unit)
This is the power management microcontroller. It manages the entire
SoC. The driver interacts with it to control power management
features like clocks, voltages, power rails, etc.
DCN (Display Controller Next)
This is the display controller. It handles the display hardware.
It is described in more details in :ref:`Display Core <amdgpu-display-core>`.
SDMA (System DMA)
This is a multi-purpose DMA engine. The kernel driver uses it for
various things including paging and GPU page table updates. It's also
exposed to userspace for use by user mode drivers (OpenGL, Vulkan,
etc.)
GC (Graphics and Compute)
This is the graphics and compute engine, i.e., the block that
encompasses the 3D pipeline and shader blocks. This is by far the
largest block on the GPU. The 3D pipeline has tons of sub-blocks. In
addition to that, it also contains the CP microcontrollers (ME, PFP, CE,
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.