On Tue, Oct 21, 2025 at 10:55 AM Rodrigo Siqueira <[email protected]> wrote: > > Hi Alex/Lijo, > > On 10/20, Alex Deucher wrote: > > On Mon, Oct 20, 2025 at 3:56 PM Rodrigo Siqueira <[email protected]> > > wrote: > > > > > > This commit expands the overall explanation about AMD GPU IPs by adding > > > more details about their interconnection. Note that this commit includes > > > a diagram that provides additional information. > > > > > > Cc: Alex Deucher <[email protected]> > > > Cc: Christian König <[email protected]> > > > Cc: Timur Kristóf <[email protected]> > > > Signed-off-by: Rodrigo Siqueira <[email protected]> > > > --- > > > .../gpu/amdgpu/amd_overview_block.svg | 674 ++++++++++++++++++ > > > Documentation/gpu/amdgpu/amdgpu-glossary.rst | 3 + > > > Documentation/gpu/amdgpu/driver-core.rst | 25 + > > > 3 files changed, 702 insertions(+) > > > create mode 100644 Documentation/gpu/amdgpu/amd_overview_block.svg > > > > > > diff --git a/Documentation/gpu/amdgpu/amd_overview_block.svg > > > b/Documentation/gpu/amdgpu/amd_overview_block.svg > > > new file mode 100644 > > > index 000000000000..8d9ae95bd9a5 > > > --- /dev/null > > > +++ b/Documentation/gpu/amdgpu/amd_overview_block.svg > > > > Got a link to the diagram anywhere? These looked good at XDC. > > After reading your comment in the cover-letter about this diagram, I > made the following modifications: > > 1. Connect PSP to UMC. > 2. Connect PSP to GC. > 3. Connect GC to UMC. > 4. To avoid confusion, I moved the green block outside each specific IP. > I also changed the explanation about these parts in the text, see it > below. > > Here is the new version: > > https://people.igalia.com/siqueira/kernel-doc-imgs/v4/amd_overview_block.svg > > What do you think?
Looks good! > > > > > > @@ -0,0 +1,674 @@ > > > +<?xml version="1.0" encoding="UTF-8" standalone="no"?> > > > +<!-- Created with Inkscape (http://www.inkscape.org/) --> > > > + > > > +<svg > > <snip> > > > > +</svg> > > > diff --git a/Documentation/gpu/amdgpu/amdgpu-glossary.rst > > > b/Documentation/gpu/amdgpu/amdgpu-glossary.rst > > > index eb72e6f6d4f1..a3f9565d655b 100644 > > > --- a/Documentation/gpu/amdgpu/amdgpu-glossary.rst > > > +++ b/Documentation/gpu/amdgpu/amdgpu-glossary.rst > > > @@ -227,6 +227,9 @@ we have a dedicated glossary for Display Core at > > > TOC > > > Table of Contents > > > > > > + UMC > > > + Unified Memory Controller > > > + > > > UMSCH > > > User Mode Scheduler > > > > > > diff --git a/Documentation/gpu/amdgpu/driver-core.rst > > > b/Documentation/gpu/amdgpu/driver-core.rst > > > index 3ce276272171..13f13e2e5497 100644 > > > --- a/Documentation/gpu/amdgpu/driver-core.rst > > > +++ b/Documentation/gpu/amdgpu/driver-core.rst > > > @@ -77,6 +77,31 @@ VCN (Video Core Next) > > > decode. It's exposed to userspace for user mode drivers (VA-API, > > > OpenMAX, etc.) > > > > > > +It is important to note that these blocks can interact with each other. > > > The > > > +picture below illustrates some of the components and their > > > interconnection: > > > + > > > +.. kernel-figure:: amd_overview_block.svg > > > + > > > +In the diagram, memory-related blocks are represented by a green color. > > > Notice > > > +that specific IPs have a green block that represents a small hardware > > > block > > > +named 'hub', which is responsible for interfacing with memory (pre-vega > > > devices > > > +have a dedicated block for that, named GMC). In the driver code, you can > > > +identify this component by looking for the suffix hub, for example: > > > gfxhub, > > > +dchub, mmhub, vmhub, etc. All memory hubs are connected in the UMC, > > > which in > > > > All memory hubs are connected to the UMCs, which in > > Based on Lijo's comment and Alex's comment in the cover-latter, I > rewrote this paragraph to: > > In the diagram, memory-related blocks are shown in green. Notice that > specific IPs have a green square that represents a small hardware block > named 'hub', which is responsible for interfacing with memory. All > memory hubs are connected in the UMCs, which in turn are connected to > memory blocks. As a note, pre-vega devices have a dedicated block for > the Graphic Memory Controller (GMC), which was replaced by UMC in new > architectures. In the driver code, you can identify this component by GMC was replaced by UMC + hubs. > looking for the suffix hub, for example: gfxhub, dchub, mmhub, vmhub, > etc. Keep in mind that the component's interaction with the memory block > may vary across architectures. For example, on Navi and newer, GC and > SDMA are both attached to GCHUB; on pre-Navi, SDMA goes through MMHUB; > VCN, JPEG, and VPE go through MMHUB; DCN goes through DCHUB. > > What do you think? Looks good to me. > > Also, keep in mind that this text is part of the below page that already > have some comments about GMC. > > https://origin.kernel.org/doc/html/latest/gpu/amdgpu/driver-core.html > > > > > > +turn is connected to memory blocks. > > > + > > > +There is some level of protection for certain elements in memory, and > > > the PSP > > > +plays an essential role in this area. For example, when a specific > > > firmware is > > > +loaded into the memory, PSP takes an action to ensure that the firmware > > > has a > > > +valid signature. > > > > It also stores the firmware images in a protected memory area (TMR = > > Trusted Memory Area) so the OS or driver can't corrupt it at runtime > > after it's been validated. > > > > > Another use of PSP is to support the TA (e.g., HDCP) and > > > > TA = Trusted Application > > Basically small application that runs on the trusted processor and > > handles a trusted operation. > > > > > +encrypted memory via TMZ. > > > > TMZ (Trusted Memory Zone -- encrypted memory for content protection). > > > > I also rewrote this paragraph to address both of your comments: > > There is some protection for certain memory elements, and the PSP plays > an essential role in this area. When a specific firmware is loaded into > memory, the PSP takes steps to ensure it has a valid signature. It also > stores firmware images in a protected memory area named Trusted > Memory Area (TMR), so the OS or driver can't corrupt them at runtime. Another > use of PSP is to support the Trusted Application (TA), which is > basically a small application that runs on the trusted processor and use of PSP is to support Trusted Applications (TA), which are basically small applications that run on the trusted processor and > handles a trusted operation (e.g., HDCP). PSP is also used for encrypted > memory for content protection via Trusted Memory Zone (TMZ). > > Does it looks good for a v4? > > > > + > > > +Another IP that deserves attention is the SMU, as it is connected to all > > > the > > > +other IPs. SMU will help put the GPU in optimal utilization by taking > > > into > > > +account performance and power consumption. SMU helps other blocks to set > > > up a > > > +proper clock configuration. Another feature of SMU is the support for > > > resetting > > > +every component. > > > > How about something like: > > > > Another important IP is the SMU. It handles reset distribution as > > well as clock and power management for all of the IPs on the SoC. > > Ok, how about this paragraph for the v4: > > Another critical IP is the SMU. It handles reset distribution as well as > clock and power management for all of the IPs on the SoC. SMU also helps > to optimize GPU utilization by balancing performance and power > consumption. Finally, SMU also supports thermal management. I would include thermal in the first sentence. E.g., "clock, thermal, and power management" Also, the use of "utilization" seems weird. I think of utilization as the resources used on the GPU. Use of the GPU resources is managed by the scheduler and the driver. The SMU tries to align performance with demand. Thanks, Alex > > Thanks > Siqueira > > > > > Alex > > > > > + > > > .. _pipes-and-queues-description: > > > > > > GFX, Compute, and SDMA Overall Behavior > > > -- > > > 2.51.0 > > > > > -- > Rodrigo Siqueira
