On Sat, Jul 19, 2025 at 7:58 PM Yann Dirson <ydir...@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
