Re: [PATCH v2 5/6] Documentation/gpu: Add basic overview of DC pipeline

From: Yann Dirson <ydirson@free.fr>
To: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Cc: linux-doc@vger.kernel.org, qingqing zhuo <qingqing.zhuo@amd.com>,
	roman li <roman.li@amd.com>,
	amd-gfx@lists.freedesktop.org,
	aurabindo pillai <aurabindo.pillai@amd.com>,
	nicholas choi <nicholas.choi@amd.com>,
	dri-devel@lists.freedesktop.org,
	Alex Deucher <alexander.deucher@amd.com>,
	bhawanpreet lakha <bhawanpreet.lakha@amd.com>,
	Christian Koenig <christian.koenig@amd.com>,
	Simon Ser <contact@emersion.fr>,
	Michel Daenzer <michel@daenzer.net>,
	Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>,
	Marek Olsak <marek.olsak@amd.com>, Roman Gilg <subdiff@gmail.com>,
	Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>,
	Harry Wentland <Harry.Wentland@amd.com>,
	Mark Yacoub <markyacoub@chromium.org>,
	Sean Paul <seanpaul@chromium.org>,
	Pekka Paalanen <ppaalanen@gmail.com>,
	Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH v2 5/6] Documentation/gpu: Add basic overview of DC pipeline
Date: Fri, 3 Dec 2021 22:06:39 +0100 (CET)	[thread overview]
Message-ID: <480467972.18829393.1638565599646.JavaMail.root@zimbra39-e7> (raw)
In-Reply-To: <20211202160132.2263330-6-Rodrigo.Siqueira@amd.com>

> De: "Rodrigo Siqueira" <Rodrigo.Siqueira@amd.com>
> 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@amd.com>
> ---
>  .../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
> 
> 