> De: "Rodrigo Siqueira" <Rodrigo.Siqueira@xxxxxxx> > Objet: [PATCH v2 5/6] Documentation/gpu: Add basic overview of DC pipeline > > This commit describes how DCN works by providing high-level diagrams > with an explanation of each component. In particular, it details the > Global Sync signals. > > Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@xxxxxxx> > --- > .../gpu/amdgpu/display/config_example.svg | 414 ++++++ > .../amdgpu/display/dc_pipeline_overview.svg | 1125 > +++++++++++++++++ > .../gpu/amdgpu/display/dcn-overview.rst | 168 +++ > .../gpu/amdgpu/display/global_sync_vblank.svg | 485 +++++++ > Documentation/gpu/amdgpu/display/index.rst | 23 +- > 5 files changed, 2203 insertions(+), 12 deletions(-) > create mode 100644 > Documentation/gpu/amdgpu/display/config_example.svg > create mode 100644 > Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg > create mode 100644 Documentation/gpu/amdgpu/display/dcn-overview.rst > create mode 100644 > Documentation/gpu/amdgpu/display/global_sync_vblank.svg > ... > diff --git a/Documentation/gpu/amdgpu/display/dcn-overview.rst > b/Documentation/gpu/amdgpu/display/dcn-overview.rst > new file mode 100644 > index 000000000000..47e9a70de8ae > --- /dev/null > +++ b/Documentation/gpu/amdgpu/display/dcn-overview.rst > @@ -0,0 +1,168 @@ > +======================= > +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: Maybe a note on MMHUBBUB is missing ? > + > +* **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. > + > +* **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; > +3. Config interface: Responsible to configure blocks; > +4. Sideband signals: All other signals that do not fit the previous > one. > + > +These signals are essential and play an important role in DCN. > Nevertheless, > +the Global Sync deserves an extra level of detail described in the > next > +section. > + > +All of these components are represented by a data structure named > dc_state. > +From DCHUB to MPC, we have a representation called dc_plane; from > MPC to OPTC, > +we have dc_stream, and the output (DIO) is handled by dc_link. Keep > in mind > +that HUBP accesses a surface using a specific format read from > memory, and our > +dc_plane should work to convert all pixels in the plane to something > that can > +be sent to the display via dc_stream and dc_link. > + > +Front End and Back End > +---------------------- > + > +Display pipeline can be broken down into two components that are > usually > +referred as **Front End (FE)** and **Back End (BE)**, where FE > consists of: > + > +* DCHUB (Mainly referring to a subcomponent named HUBP) > +* DPP > +* MPC > + > +On the other hand, BE consist of > + > +* OPP > +* OPTC > +* DIO (DP/HDMI stream encoder and link encoder) > + > +OPP and OPTC are two joining blocks between FE and BE. On a side > note, this is > +a one-to-one mapping of the link encoder to PHY, but we can > configure the DCN > +to choose which link encoder to connect to which PHY. FE's main > responsibility > +is to change, blend and compose pixel data, while BE's job is to > frame a > +generic pixel stream to a specific display's pixel stream. > + > +Data Flow > +--------- > + > +Initially, data is passed in from VRAM through Data Fabric (DF) in > native pixel > +formats. Such data format stays through till HUBP in DCHUB, where > HUBP unpacks > +different pixel formats and outputs them to DPP in uniform streams > through 4 > +channels (1 for alpha + 3 for colors). > + > +The Converter and Cursor (CNVC) in DPP would then normalize the data > +representation and convert them to a DCN specific floating-point > format (i.e., > +different from the IEEE floating-point format). In the process, CNVC > also > +applies a degamma function to transform the data from non-linear to > linear > +space to relax the floating-point calculations following. Data would > stay in > +this floating-point format from DPP to OPP. > + > +Starting OPP, because color transformation and blending have been > completed > +(i.e alpha can be dropped), and the end sinks do not require the > precision and > +dynamic range that floating points provide (i.e. all displays are in > integer > +depth format), bit-depth reduction/dithering would kick in. In OPP, > we would > +also apply a regamma function to introduce the gamma removed earlier > back. > +Eventually, we output data in integer format at DIO. > + > +Global Sync > +----------- > + > +Many DCN registers are double buffered, most importantly the surface > address. > +This allows us to updated DCN hardware atomically for page flips, as > well as to update ? > +for most other updates that don't require enabling or disabling of > new pipes. > + > +(Note: There are many scenarios when DC will decide to reserve extra > pipes > +in order to support outputs that need a very high pixel clock, or > for > +power saving purposes.) > + > +These atomic register updates are driven by global sync signals in > DCN. In > +order to understand how atomic updates interact with DCN hardware, > and how DCN > +signals page flip and vblank events it is helpful to understand how > global sync > +is programmed. > + > +Global sync consists of three signals, VSTARTUP, VUPDATE, and > VREADY. These are > +calculated by the Display Mode Library - DML > (drivers/gpu/drm/amd/display/dc/dml) > +based on a large number of parameters and ensure our hardware is > able to feed > +the DCN pipeline without underflows or hangs in any given system > configuration. > +The global sync signals always happen during VBlank, are independent > from the > +VSync signal, and do not overlap each other. > + > +VUPDATE is the only signal that is of interest to the rest of the > driver stack > +or userspace clients as it signals the point at which hardware > latches to > +atomically programmed (i.e. double buffered) registers. Even though > it is > +independent of the VSync signal we use VUPDATE to signal the VSync > event as it > +provides the best indication of how atomic commits and hardware > interact. > + > +Since DCN hardware is double-buffered the DC driver is able to > program the > +hardware at any point during the frame. > + > +The below picture illustrates the global sync signals: > + > +.. kernel-figure:: global_sync_vblank.svg > + > +These signals affect core DCN behavior. Programming them incorrectly > will lead > +to a number of negative consequences, most of them quite > catastrophic. > + > +The following picture shows how global sync allows for a mailbox > style of > +updates, i.e. it allows for multiple re-configurations between > VUpdate > +events where only the last configuration programmed before the > VUpdate signal > +becomes effective. > + > +.. kernel-figure:: config_example.svg ... > diff --git a/Documentation/gpu/amdgpu/display/index.rst > b/Documentation/gpu/amdgpu/display/index.rst > index a443866332ac..fe2ecad8df81 100644 > --- a/Documentation/gpu/amdgpu/display/index.rst > +++ b/Documentation/gpu/amdgpu/display/index.rst > @@ -2,28 +2,27 @@ > drm/amd/display - Display Core (DC) > =================================== > > -*placeholder - general description of supported platforms, what dc > is, etc.* > - > -Because it is partially shared with other operating systems, the > Display Core > -Driver is divided in two pieces. > +AMD display engine is partially shared with other operating systems; > for this > +reason, our Display Core Driver is divided into two pieces: > > 1. **Display Core (DC)** contains the OS-agnostic components. Things > like > hardware programming and resource management are handled here. > 2. **Display Manager (DM)** contains the OS-dependent components. > Hooks to the > amdgpu base driver and DRM are implemented here. > > -It doesn't help that the entire package is frequently referred to as > DC. But > -with the context in mind, it should be clear. > +The display pipe is responsible for "scanning out" a rendered frame > from the > +GPU memory (also called VRAM, FrameBuffer, etc.) to a display. In > other words, > +it would: > > -When CONFIG_DRM_AMD_DC is enabled, DC will be initialized by default > for > -supported ASICs. To force disable, set `amdgpu.dc=0` on kernel > command line. > -Likewise, to force enable on unsupported ASICs, set `amdgpu.dc=1`. > +1. Read frame information from memory; > +2. Perform required transformation; > +3. Send pixel data to sink devices. > > -To determine if DC is loaded, search dmesg for the following entry: > +If you want to learn more about our driver details, take a look at > the below > +table of content: > > .. toctree:: > > display-manager.rst > dc-debug.rst > - > -``Display Core initialized with <version number here>`` > + dcn-overview.rst > -- > 2.25.1 > >
