On 2022-06-15 07:12, Pekka Paalanen wrote:
On Mon, 13 Jun 2022 16:01:11 -0400
Rodrigo Siqueira <Rodrigo.Siqueira@xxxxxxx> wrote:
In the DCN code, we constantly talk about hardware pipeline, pipeline,
or even just pipes, which is a concept that is not obvious to everyone.
For this reason, this commit expands the DCN overview explanation by
adding a new section that describes what a pipeline is from the DCN
perspective.
Cc: Harry Wentland <harry.wentland@xxxxxxx>
Cc: Nicholas Kazlauskas <Nicholas.Kazlauskas@xxxxxxx>
Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@xxxxxxx>
Cc: Hersen Wu <hersenxs.wu@xxxxxxx>
Cc: Alex Hung <alex.hung@xxxxxxx>
Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@xxxxxxx>
Cc: Leo Li <sunpeng.li@xxxxxxx>
Cc: Simon Ser <contact@xxxxxxxxxxx>
Cc: Pekka Paalanen <pekka.paalanen@xxxxxxxxxxxxx>
Cc: Sean Paul <seanpaul@xxxxxxxxxxxx>
Cc: Mark Yacoub <markyacoub@xxxxxxxxxxxx>
Cc: Pierre-Loup <pgriffais@xxxxxxxxxxxxxxxxx>
Cc: Michel Dänzer <michel.daenzer@xxxxxxxxxxx>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@xxxxxxx>
---
.../gpu/amdgpu/display/dcn-overview.rst | 58 +
.../amdgpu/display/pipeline_4k_no_split.svg | 958 +++++++++++++++
.../gpu/amdgpu/display/pipeline_4k_split.svg | 1062 +++++++++++++++++
3 files changed, 2078 insertions(+)
create mode 100644 Documentation/gpu/amdgpu/display/pipeline_4k_no_split.svg
create mode 100644 Documentation/gpu/amdgpu/display/pipeline_4k_split.svg
diff --git a/Documentation/gpu/amdgpu/display/dcn-overview.rst b/Documentation/gpu/amdgpu/display/dcn-overview.rst
index f98624d7828e..430e363fccae 100644
--- a/Documentation/gpu/amdgpu/display/dcn-overview.rst
+++ b/Documentation/gpu/amdgpu/display/dcn-overview.rst
@@ -124,6 +124,64 @@ 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.
Hi,
always nice to see more docs!
Hi Pekka,
First of all, thanks for your review.
+AMD Hardware Pipeline
+---------------------
+
+When discussing graphics on Linux, the **pipeline** term is often overloaded
+with multiple meanings, and DCN adds another context to this word. In the DCN
+driver, we use the term **hardware pipeline** or **pipeline** or just **pipe**
+to indicate how many DCN blocks we are instantiating to address some specific
This seems to say that a "pipeline" is a number, a count (how many).
+configuration. DCN composes those pipelines together when the data reach the
This seems to imply that each "DCN block" is "a pipeline".
Is either true? Is a pipeline not a sequence of selected DCN blocks
instead?
In the DCN we can have different pipeline configurations. For example,
see the below picture:
https://www.kernel.org/doc/html/latest/gpu/amdgpu/display/dcn-overview.html
Let's say that our pipeline policy does not allow pipe split, in that
case we will have just one instance of each component. However, if we
decided to split our pipe, we will have more instance of the other
components (e.g., 2 DPP). I added some examples about it a little bit
below in this patch.
Try to apply my series in your local kernel [1]. That way you will be
able to open the svg files at Documentation/gpu/amdgpu/display/.
Maybe I can rephrase it, do you have some suggestions?
1. https://patchwork.freedesktop.org/series/105071/
Thanks
Siqueira
+end of the OPTC block before sending it to the display. We have this pipeline
+concept for trying to save energy and optimize bandwidth utilization while
+providing the maximum performance per watt. It is easier to discuss it if we
+dive into this topic by taking the example of a 4k display in the below
+example:
+
+.. kernel-figure:: pipeline_4k_no_split.svg
A bit too hard for me to look at SVGs from email patches, sorry.
You wouldn't happen to have a git branch available in Gitlab or Github
or even cgit somewhere I could visit with my browser?
Thanks,
pq
+
+Additionally, let's take a look at parts of the DTN log (see
+'Documentation/gpu/amdgpu/display/dc-debug.rst' for more information) since
+this log can help us to see part of this pipeline behavior in real-time::
+
+ HUBP: format addr_hi width height ...
+ [ 0]: 8h 81h 3840 2160
+ [ 1]: 0h 0h 0 0
+ [ 2]: 0h 0h 0 0
+ [ 3]: 0h 0h 0 0
+ [ 4]: 0h 0h 0 0
+ ...
+ MPCC: OPP DPP ...
+ [ 0]: 0h 0h ...
+
+The first thing to notice from the diagram and DTN log it is the fact that we
+have different clock domains for each part of the DCN blocks. In this example,
+we have just a single **pipeline** where the data flows from DCHUB to DIO, as
+we intuitively expect. Nonetheless, DCN is flexible, as mentioned before, and
+we can split this single pipe differently, as described in the below diagram:
+
+.. kernel-figure:: pipeline_4k_split.svg
+
+Now, if we inspect the DTN log again we can see some interesting changes::
+
+ HUBP: format addr_hi width height ...
+ [ 0]: 8h 81h 1920 2160 ...
+ ...
+ [ 4]: 0h 0h 0 0 ...
+ [ 5]: 8h 81h 1920 2160 ...
+ ...
+ MPCC: OPP DPP ...
+ [ 0]: 0h 0h ...
+ [ 5]: 0h 5h ...
+
+From the above example, we now split the display pipeline into two vertical
+parts of 1920x2160 (i.e., 3440x2160), and as a result, we could reduce the
+clock frequency in the DPP part. This is not only useful for saving power but
+also to better handle the required throughput. The idea to keep in mind here is
+that the pipe configuration can vary a lot according to the display
+configuration, and it is the DML's responsibility to set up all required
+configuration parameters for multiple scenarios supported by our hardware.
+
Global Sync
-----------
