Linux Documentation
 help / color / mirror / Atom feed
From: Rodrigo Siqueira Jordao <rjordrigo@amd.com>
To: Yann Dirson <ydirson@free.fr>, amd-gfx@lists.freedesktop.org
Cc: Alex Deucher <alexander.deucher@amd.com>,
	Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>,
	linux-doc@vger.kernel.org,
	Harry Wentland <harry.wentland@amd.com>
Subject: Re: [PATCH v2 2/3] Documentation/gpu: include description of AMDGPU hardware structure
Date: Mon, 13 Dec 2021 15:16:29 -0500	[thread overview]
Message-ID: <c5563e17-d978-58ee-8350-5b51593fb5bd@amd.com> (raw)
In-Reply-To: <20211210182030.3834-3-ydirson@free.fr>



On 2021-12-10 1:20 p.m., Yann Dirson wrote:
> This is Alex' description from the "gpu block diagram" thread, edited to
> fit as ReST.

Maybe you can improve this commit message by describing what you are 
documenting and also adding a link to the original discussion. Perhaps 
you can use this link:

https://www.spinics.net/lists/amd-gfx/msg71383.html


> Originally-by: Alex Deucher <alexander.deucher@amd.com>
> Signed-off-by: Yann Dirson <ydirson@free.fr>
> Acked-by: Harry Wentland <harry.wentland@amd.com>
> ---
>   Documentation/gpu/amdgpu/driver-core.rst | 81 ++++++++++++++++++++++++
>   1 file changed, 81 insertions(+)
> 
> diff --git a/Documentation/gpu/amdgpu/driver-core.rst b/Documentation/gpu/amdgpu/driver-core.rst
> index 97f9a9b68924..b870a63c64dd 100644
> --- a/Documentation/gpu/amdgpu/driver-core.rst
> +++ b/Documentation/gpu/amdgpu/driver-core.rst
> @@ -2,6 +2,87 @@
>    Core Driver Infrastructure
>   ============================
>   
> +GPU hardware structure
> +======================

How about using the camel case in the titles? I mean "GPU Hardware 
Structure".

> +
> +Each ASIC is a collection of hardware blocks.  We refer to them as
> +"IPs" (Intellectual Property blocks).  Each IP encapsulates certain
> +functionality. IPs are versioned and can also be mixed and matched.
> +E.g., you might have two different ASICs that both have SDMA 5.x IPs.

How about using "System DMA (SDMA) 5.x" instead of only saying SDMA?

Anyway, in general lgtm.

Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>

Thanks

> +The driver is arranged by IPs.  There are driver components to handle
> +the initialization and operation of each IP.  There are also a bunch
> +of smaller IPs that don't really need much if any driver interaction.
> +Those end up getting lumped into the common stuff in the soc files.
> +The soc files (e.g., vi.c, soc15.c nv.c) contain code for aspects of
> +the SoC itself rather than specific IPs.  E.g., things like GPU resets
> +and register access functions are SoC dependent.
> +
> +An APU contains more than just CPU and GPU, it also contains all of
> +the platform stuff (audio, usb, gpio, etc.).  Also, a lot of
> +components are shared between the CPU, platform, and the GPU (e.g.,
> +SMU, PSP, etc.).  Specific components (CPU, GPU, etc.) usually have
> +their interface to interact with those common components.  For things
> +like S0i3 there is a ton of coordination required across all the
> +components, but that is probably a bit beyond the scope of this
> +section.
> +
> +With respect to the GPU, we have the following major IPs:
> +
> +GMC (Graphics Memory Controller)
> +    This was a dedicated IP on older pre-vega chips, but has since
> +    become somewhat decentralized on vega and newer chips.  They now
> +    have dedicated memory hubs for specific IPs or groups of IPs.  We
> +    still treat it as a single component in the driver however since
> +    the programming model is still pretty similar.  This is how the
> +    different IPs on the GPU get the memory (VRAM or system memory).
> +    It also provides the support for per process GPU virtual address
> +    spaces.
> +
> +IH (Interrupt Handler)
> +    This is the interrupt controller on the GPU.  All of the IPs feed
> +    their interrupts into this IP and it aggregates them into a set of
> +    ring buffers that the driver can parse to handle interrupts from
> +    different IPs.
> +
> +PSP (Platform Security Processor)
> +    This handles security policy for the SoC and executes trusted
> +    applications, and validates and loads firmwares for other blocks.
> +
> +SMU (System Management Unit)
> +    This is the power management microcontroller.  It manages the entire
> +    SoC.  The driver interacts with it to control power management
> +    features like clocks, voltages, power rails, etc.
> +
> +DCN (Display Controller Next)
> +    This is the display controller.  It handles the display hardware.
> +
> +SDMA (System DMA)
> +    This is a multi-purpose DMA engine.  The kernel driver uses it for
> +    various things including paging and GPU page table updates.  It's also
> +    exposed to userspace for use by user mode drivers (OpenGL, Vulkan,
> +    etc.)
> +
> +GC (Graphics and Compute)
> +    This is the graphics and compute engine, i.e., the block that
> +    encompasses the 3D pipeline and and shader blocks.  This is by far the
> +    largest block on the GPU.  The 3D pipeline has tons of sub-blocks.  In
> +    addition to that, it also contains the CP microcontrollers (ME, PFP,
> +    CE, MEC) and the RLC microcontroller.  It's exposed to userspace for
> +    user mode drivers (OpenGL, Vulkan, OpenCL, etc.)
> +
> +VCN (Video Core Next)
> +    This is the multi-media engine.  It handles video and image encode and
> +    decode.  It's exposed to userspace for user mode drivers (VA-API,
> +    OpenMAX, etc.)
> +
> +Driver structure
> +================
> +
> +In general, the driver has a list of all of the IPs on a particular
> +SoC and for things like init/fini/suspend/resume, more or less just
> +walks the list and handles each IP.
> +
> +
>   .. _amdgpu_memory_domains:
>   
>   Memory Domains
> 


  reply	other threads:[~2021-12-13 20:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-10 18:20 [PATCH v2 0/3] Enrich amdgpu docs from recent threads Yann Dirson
2021-12-10 18:20 ` [PATCH v2 1/3] Documentation/gpu: split amdgpu/index for readability Yann Dirson
2021-12-13 20:07   ` Rodrigo Siqueira Jordao
2021-12-13 20:36     ` Alex Deucher
2021-12-10 18:20 ` [PATCH v2 2/3] Documentation/gpu: include description of AMDGPU hardware structure Yann Dirson
2021-12-13 20:16   ` Rodrigo Siqueira Jordao [this message]
2021-12-13 20:20     ` Rodrigo Siqueira Jordao
2021-12-10 18:20 ` [PATCH v2 3/3] Documentation/gpu: include description of some of the GC microcontrollers Yann Dirson
2021-12-13 20:18   ` Rodrigo Siqueira Jordao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c5563e17-d978-58ee-8350-5b51593fb5bd@amd.com \
    --to=rjordrigo@amd.com \
    --cc=Rodrigo.Siqueira@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=harry.wentland@amd.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=ydirson@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox