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

Fri Jun 17 15:11:09 UTC 2022

On 6/17/22 03:35, Pekka Paalanen wrote:
> On Thu, 16 Jun 2022 17:59:21 -0400
> Rodrigo Siqueira Jordao <Rodrigo.Siqueira at amd.com> wrote:
> 
>> 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?  
>>

I think the confusion stems from unfortunate phrasing.

Siqueira, you seem to be saying that a **pipeline** is indicating
how many DCN blocks we're instantiating. This is incorrect and
confusing. We have a number of pipelines for each SoC, e.g. 4 for
many APUs and 6 for many dGPUs.

A pipeline is a sequence of HW blocks:
HUBP > DPP > MPC > OPP > etc.

DC treats those as individual resources, so we build a pipeline
conceptually by taking resources for all individual HW blocks
to compose one pipeline but in actuality (in HW) these blocks are
not arbitrarily configurable. What we can do is combine pipes at
the MPC as such

HUBP > DPP > MPC > OPP > output
HUBP > DPP > MPC ^

In addition the DSC block can be assigned to pipelines as needed.

So, in short we have a number of pipelines per SoC. If we have 4 pipes
we have 4 HUBPs, 4 DPPs, 4 MPCc, etc. There are few exceptions to that,
like the DSC block.

On the output side we have a number of different encoders that are attached
to our output connectors. Each pipe is routed to the appropriate encoder
for the display output.

Harry

>> In the DCN we can have different pipeline configurations. For example, 
>> see the below picture:
>>
>>  
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kernel.org%2Fdoc%2Fhtml%2Flatest%2Fgpu%2Famdgpu%2Fdisplay%2Fdcn-overview.html&data=05%7C01%7Charry.wentland%40amd.com%7C5c60cfb7c2e5483e1b0d08da5033f013%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637910481695853125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=TX6JmSkn2ybJSqtOz7DRl4q745qzsCLYSkQ0RvAXsrk%3D&reserved=0
>>
>> 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/.
> 
> Sorry, that's too much to ask for patch review on a project I don't
> work on.
> 
>> Maybe I can rephrase it, do you have some suggestions?
> 
> I'm not sure what your definition of a pipeline is. If you have split
> blocks, does that mean you have one pipeline or multiple pipelines?
> Does block splitting allow to create multiple pipelines in the sense
> that they do not all contain the exact same blocks?
> 
> The only thing I could suggest is to not say that a pipeline is a
> count. That would be done by replacing "to indicate how many DCN
> blocks" by "to indicate which DCN blocks".
> 
> 
> Thanks,
> pq
> 
>> 1. https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F105071%2F&data=05%7C01%7Charry.wentland%40amd.com%7C5c60cfb7c2e5483e1b0d08da5033f013%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637910481695853125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=MYx6R8tIvFu6f46Rj7GWH4MIfa7bjYjdYitFnc6wNZs%3D&reserved=0
>>
>> 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