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:20:19 -0500	[thread overview]
Message-ID: <2750b51f-87ba-9393-8d75-711701a7437e@amd.com> (raw)
In-Reply-To: <c5563e17-d978-58ee-8350-5b51593fb5bd@amd.com>



On 2021-12-13 3:16 p.m., Rodrigo Siqueira Jordao wrote:
> 
> 
> 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.

I forgot to ask you to add a link to the new DCN documentation here.

Thanks

>> +
>> +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:20 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
2021-12-13 20:20     ` Rodrigo Siqueira Jordao [this message]
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=2750b51f-87ba-9393-8d75-711701a7437e@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