Documentation/gpu/amdgpu/display/dcn-overview.rst
Source file repositories/reference/linux-study-clean/Documentation/gpu/amdgpu/display/dcn-overview.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/gpu/amdgpu/display/dcn-overview.rst- Extension
.rst- Size
- 10551 bytes
- Lines
- 233
- 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
.. _dcn_overview:
=======================
Display Core Next (DCN)
=======================
To equip our readers with the basic knowledge of how AMD Display Core Next
(DCN) works, we need to start with an overview of the hardware pipeline. Below
you can see a picture that provides a DCN overview, keep in mind that this is a
generic diagram, and we have variations per ASIC.
.. kernel-figure:: dc_pipeline_overview.svg
Based on this diagram, we can pass through each block and briefly describe
them:
* **Display Controller Hub (DCHUB)**: This is the gateway between the Scalable
Data Port (SDP) and DCN. This component has multiple features, such as memory
arbitration, rotation, and cursor manipulation.
* **Display Pipe and Plane (DPP)**: This block provides pre-blend pixel
processing such as color space conversion, linearization of pixel data, tone
mapping, and gamut mapping.
* **Multiple Pipe/Plane Combined (MPC)**: This component performs blending of
multiple planes, using global or per-pixel alpha.
* **Output Pixel Processing (OPP)**: Process and format pixels to be sent to
the display.
* **Output Pipe Timing Combiner (OPTC)**: It generates time output to combine
streams or divide capabilities. CRC values are generated in this block.
* **Display Output (DIO)**: Codify the output to the display connected to our
GPU.
* **Display Writeback (DWB)**: It provides the ability to write the output of
the display pipe back to memory as video frames.
* **Multi-Media HUB (MMHUBBUB)**: Memory controller interface for DMCUB and DWB
(Note that DWB is not hooked yet).
* **DCN Management Unit (DMU)**: It provides registers with access control and
interrupts the controller to the SOC host interrupt unit. This block includes
the Display Micro-Controller Unit - version B (DMCUB), which is handled via
firmware.
* **DCN Clock Generator Block (DCCG)**: It provides the clocks and resets
for all of the display controller clock domains.
* **Azalia (AZ)**: Audio engine.
The above diagram is an architecture generalization of DCN, which means that
every ASIC has variations around this base model. Notice that the display
pipeline is connected to the Scalable Data Port (SDP) via DCHUB; you can see
the SDP as the element from our Data Fabric that feeds the display pipe.
Always approach the DCN architecture as something flexible that can be
configured and reconfigured in multiple ways; in other words, each block can be
setup or ignored accordingly with userspace demands. For example, if we
want to drive an 8k@60Hz with a DSC enabled, our DCN may require 4 DPP and 2
OPP. It is DC's responsibility to drive the best configuration for each
specific scenario. Orchestrate all of these components together requires a
sophisticated communication interface which is highlighted in the diagram by
the edges that connect each block; from the chart, each connection between
these blocks represents:
1. Pixel data interface (red): Represents the pixel data flow;
2. Global sync signals (green): It is a set of synchronization signals composed
by VStartup, VUpdate, and VReady;
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.