A few more items for the glossary, and understanding GPU switching

[Alex Deucher]

On Sat, Jul 19, 2025 at 7:58 PM Yann Dirson <ydirson at free.fr> wrote:
>
> Hello,
>
> Back to reading some amdgpu code, I stumbled on a few things that probably ought
> to be added to the glossary.  Well, to be fair, I actually just had to read the kernel
> logs to see most of them, so those likely make sense to explain.
>
> * ATPX (could not find anything about that on the net). "PX" alone seems to be used
>   as a synonym.  Referred to as "ATPX power control", and closely linked to vga_switcheroo.

ATPX is the name of an ACPI method.  It stands for ATI PowerXpress.
PowerXpress was the marketing name associated with dGPU d3cold when it
was a vendor specific feature.  Eventually this was standardized by
ACPI and there are standard methods for controlling device power in
the ACPI layer.

>   This seems to be a preferred alternative to
>   BOCO and BACO, but those are only tersely mentioned in the glossary, and could maybe
>   use more details.  There also seem to be the notion of "ATPX hybrid" (which apparently
>   applies to the RENOIR in my laptop)

The ATPX method still exists on some laptops with a dGPU, but it no
longer controls the dGPU power.  That is handled via standard ACPI
methods now and has been for a while.  The driver checks the ATPX
method to determine whether it should use ATPX or the standard ACPI
interfaces for power control.

> * MACO and BAMACO looks similarly related (I may have missed some ;)

BOCO/BACO/BAMACO are all names for various low power states GPU can be put into.

B = Bus
M = Memory
C = Chip
A = Active
O = Off

So BOCO would be Bus Off Chip Off.  Basically the entire PCIe device
is powered down.  Since the PCIe device is powered down, it no longer
appears on the PCIe bus.  This is handled by either ATPX or the
standard ACPI d3cold methods.  BACO is Bus Active Chip Off.  In BACO,
the bus interface is still up, but the chip is powered down, so the
device still shows up on the PCIe bus, but most of the chip is powered
down.  BAMACO and BOMACO are similar to BACO and BOCO, but they keep
VRAM powered up so VRAM contents are not lost when the device is
powered down.

> * CRAT seems to be known as "Component Resource Attribute Table" ACPI table according
>   to various Internet sources (it is listed as "Component Resource Association Table"
>   in kfd_crat.h, do we want to adjust this?), but I could not locate any details on this
>   table (ACPI 6.5 seems to list it as deprecated, but even 6.4 just gives erroneous
>   information, "Links to ACPI-related Documents" in　https://uefi.org/acpi has no info)
>   Is it useful to add to the glossary, with some info about its role in the amdgpu context?
>

CRAT was an ACPI table which was used for topology information for
APUs for ROCm.  Unfortunately, not all board vendors properly
supported the table, so the driver has a fallback to handle missing
CRAT tables.  It hasn't been used for a long time.

>
> Now about the init on my MSI Bravo17 (Renoir APU, Navi10 dGPU)...
>
> What I understand about ATPX is that this is a "PX system", as shown by amdgpu_atpx_detect()
> logging:
>  amdgpu: vga_switcheroo: detected switching method \_SB_.PCI0.GP17.VGA_.ATPX handle
>
> So amdgpu seems to imply vga_switcheroo is supposed to get initialized at some point, right?

IIRC, the switcheroo code looks for certain ACPI methods on its own as well.

> Similarly with another similar-looking log:
>
>  snd_hda_intel 0000:03:00.1: Handle vga_switcheroo audio client
>
> But no other log see vga_switcheroo actually getting enabled (and the debugfs dir does not
> appear either, confirming this).
>
> That is, no call to vga_switcheroo_enable() gets done (both would trigger a
> "vga_switcheroo: enabled" log).  The 2 call chains from amdgpu would be:
>
> amdgpu_init()
> -> amdgpu_register_atpx_handler()
>    -> vga_switcheroo_register_handler()
>
> amdgpu_device_init()
> -> vga_switcheroo_register_client()
>    -> register_client()
>
> Booting with "tp_printk ftrace=function ftrace_filter=vga_switcheroo_register_handler,vga_switcheroo_register_client,vga_switcheroo_ready" it gets obvious vga_switcheroo_register_client() never not gets called.
>
> The answer seems to lie in amdgpu_device_supports_px(), but I'm not sure to get everything straight here:
> amdgpu_device_supports_px() is documented as "Returns true if the device is a dGPU with ATPX power control",
> but amdgpu_is_atpx_hybrid() it calls seems to take info from a single static struct, so does the quoted
> docstring really make sense?  And if an "APTX hybrid" system does not support vga_switcheroo in the end,
> couldn't we just avoid any mention of vga_switcheroo in the logs (since it is indeed amdgpu itself sending
> the user on that track), or at least just print once that it is not supported and a short reason?

ATPX was also used for mux switching on laptops which had a display
mux between the APU and the dGPU.  The switcheroo stuff was for
handling that.
The message comes from the audio driver.  I think it just checks for
the presence of ATPX and sets up switcheroo on the audio side. Someone
could improve the logic in the audio driver (and the switcheroo code
as well) to follow what the GPU driver does if you wanted to avoid
those messages.

>
> Best regards,
> --
> Yann