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