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! > +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? > +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 > ----------- >
