[PATCH 2/3] Documentation/gpu: Add an explanation about the DCN pipeline

Thu Jun 16 21:59:21 UTC 2022

On 2022-06-15 07:12, Pekka Paalanen wrote:
> On Mon, 13 Jun 2022 16:01:11 -0400
> Rodrigo Siqueira <Rodrigo.Siqueira at amd.com> 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 at amd.com>
>> Cc: Nicholas Kazlauskas <Nicholas.Kazlauskas at amd.com>
>> Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha at amd.com>
>> Cc: Hersen Wu <hersenxs.wu at amd.com>
>> Cc: Alex Hung <alex.hung at amd.com>
>> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer at amd.com>
>> Cc: Leo Li <sunpeng.li at amd.com>
>> Cc: Simon Ser <contact at emersion.fr>
>> Cc: Pekka Paalanen <pekka.paalanen at collabora.com>
>> Cc: Sean Paul <seanpaul at chromium.org>
>> Cc: Mark Yacoub <markyacoub at chromium.org>
>> Cc: Pierre-Loup <pgriffais at valvesoftware.com>
>> Cc: Michel Dänzer <michel.daenzer at mailbox.org>
>> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira at amd.com>
>> ---
>>   .../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
>>   -----------
>>   