[Solved]dGPU stuck at 0Mhz, Not Detected by supergfxctl, apps using dG

Beefy Joe · 2024-10-26 23:34:04

Solution: Add these paramaters to your /boot/loader/entries/linux.conf (note you probably don't need all of these add one by one until it's fixed, I just got impatient) Roll back supergfxctl to v5.2.1 (5.2.4 is broken, fix has been submitted in a merge request and should be resolved on the next release) For Steam, set 'PrefersNonDefaultGPU' in the steam.desktop file to false, doesn't launch otherwise. Run games in steam with launch argument 'DRI_PRIME=1 %command%' to make steam game launch on dGPU.

amdgpu.dcdebugmask=0x10
amdgpu.dpm=1
amdgpu.ppfeaturemask=0xffffffff
amdgpu.dc=1
amdgpu.si_support=1
amdgpu.cik_support=1

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Original Post
Hello, I am reaching out for help after exhausting Google, Arch Wiki, Reddit, and the reported issues in the Asus Linux discord.

Problems:
Laptop is unable to use dGPU in Hybrid or MUX dGPU only mode.
With the Mux switch set to dGPU only, laptop display is extremely laggy with graphics artifacting in a solid line at the top of the display, only updates frames on mouse movement.
Applications launched on the dGPU crash. supergfxctl is unable to detect dGPU. Laptop screen is unable to output more than 60hz, even when 165hz is selected in KDE settings and kscreen-dcotor shows 165hz is selected.

Questions:
How do I get my dGPU detected by supergfxctl, and running more than 0Mhz?
How do I get applications to launch and not crash when using the dGPU?
How do I get the display to run at 165hz?

Long description/history/symptoms/logs:
After getting through the arch installation and setting up my desktop environment, correct amdgpu drivers, and mesa/vulkan packages, I immediately went and installed the relavant AsusLinux packages, asusctl, rog-control-center and supergfxctl, per the recomendation on AsusLinux arch wiki page (I had not yet installed the Asus Linux Custom Kernel yet). I followed steps on Asus Linux's arch setup guide for, Repo, Asusctl, Supergfxctl, and rog-control-center . I had installed steam to start trying to get my games installed. After installing steam, trying to run the steam runtime resulted in the application opening in a black window and crashing in a loop. I exited steam from the tasktray. Reading on the arch wiki for .desktop files , I figured that I would need to modify the steam.desktop file. After copying the steam.desktop to the apropriate directory in ~ for application entries, I modified the following lines in the steam.desktop file from true to false.

PrefersNonDefaultGPU=false
X-KDE-RunOnDiscreteGpu=false

Running steam with these changes to the .desktop file allowed steam to start. At this point I still hadn't realized that my dGPU was not being detected. I had then noticed that my display was not rendering at 165hz, even though it was set to be 165hz in the KDE Display Settings. Noticed I was still in Hybrid mode according to supergfxctl and asusctl outputs. So I then tried to use supergfxctl to change my laptop from Hybrid to Dedicated only with the mux switch to see if this would allow for 165hz output from my display, but when I ran 'supergfxctl -S', I got the following error message;

Graphics mode change error.
Please check `journalctl -b -u supergfxd`, and `systemctl status supergfxd`
GFX fail: get_runtime_status: Could not find dGPU

I thought that this was weird because neofetch was clearly displaying the dGPU in my prompt, and the Thermal Monitor plasmid, was showing temperatures for both integrated and dedicated GPUs.

Per the FAQ page on AsusLinux under the section, "Switching Graphics modes (integrated/hybrid/dedicated) doesn't seem to work". I tried the following;

Ran

journalctl -b -u supergfxd

Saw,

ERROR: get_runtime_status: Could not find dGPU

Booted into Windows on my other drive, checked the Asus Armoury Crate Application, made sure that was set to automatic mode. I rebooted and checked journal for supergfxctl again with the same error. To make sure that the dGPU was not disabled by Windows at the bios level still, I went back to Windows and in Armoury Crate I changed the graphics setting to Ultimate mode to force the Mux Switch on in Windows. Rebooted once back to windows to ensure it was on, and then shutdown and booted into Arch. On this boot into arch, the machine definitely had to be using the dGPU because the entire screen was extremely laggy, there was graphics artifacting in a line on the top of the screen, logging into the DE things were only updating frames when I would move the mouse, and more severe artifacting. I managed to open up a terminal and run nvtop, where I could see that the dGPU was stuck at 0Mhz until I would move the mouse then it would go up to maybe 100mhz when I would move my mouse and then immediately back down to 0Mhz when I would stop moving the mouse.
From a new terminal session I ran 'journalctl -b -u supergfxd' again while in AsusMuxDgpu mode, this time I saw something interesting;

Oct 25 21:32:08 a16tuf-arch supergfxd[756]: DEBUG: do_driver_action: action = modprobe, []
Oct 25 21:32:08 a16tuf-arch supergfxd[756]: ERROR: Action thread errored: The module nvidia_drm is missing
Oct 25 21:32:08 a16tuf-arch systemctl[790]: Failed to start nvidia-powerd.service: Unit nvidia-powerd.service not found.
Oct 25 21:32:08 a16tuf-arch supergfxd[756]: WARN: true nvidia-powerd.service failed: Some(5)
Oct 25 21:32:08 a16tuf-arch supergfxd[756]: DEBUG: Did CommandArgs { inner: ["start", "nvidia-powerd.service"] }
....
Oct 25 21:32:08 a16tuf-arch supergfxd[756]: WARN: DiscreetGpu:? no devices??
Oct 25 21:32:08 a16tuf-arch supergfxd[756]: WARN: ASUS GPU MUX is in discreet mode

I found this very weird because I did not install any nvidia drivers on my system.
Because this gui session was painfully unusable, I used 'supergfxctl -m Hybrid' to return to hybrid mode, rebooted, and was back to a usable GUI session.

Now I began investigating the 'lspci -knn' output and 'journalctl -b' to verify that the system was actually recognizing the dGPU.

lspci output
lscpi output

journalctl output (can be provided if asked, i just need to censor sensitive information)

I can see that the system is recognizing the dGPU and it is using the correct amdgpu drivers.

I then tried to switch my kernel to the AsusLinux custom g14 kernel, repeated all of the steps above, but wound up with the exact same results.

At this point I am stuck, and cannot find a similar situation for an all AMD laptop like mine. If anyone can help me troubleshoot this further, provide suggestions, or alternative software for solving or working around my questions at the begining, I would be extremely thankful.

Thank you for taking the time to read this report, and if you take the time to help, double thank you!

System specs:
Make - Asus
Model - FA617NT
Model Name - TUF A16 Advantage Edition
CPU - AMD Ryzen 7 7735HS
iGPU - AMD ATI Radeon 680M
dGPU - AMD ATI Radeon RX7700S

System Environment/Packages of Note:
Dual Boot: Windows and Windows Bootloaders are on a completely separate drive from the Arch Linux installation. Fast Boot is Disabled in Windows Power Settings and the BIOS.
all installed packages can be found here

Last edited by Beefy Joe (2024-10-27 08:33:49)

Beefy Joe · 2024-10-27 06:16:31

Updates, 165hz on iGPU issue fixed by adding
amdgpu.dcdebugmask=0x10
To the linux.conf file for bootloader entries.

Updates, rolling back to supergfxctl version 5.2.1 fixed the issue with supergfxctl not finding the dGPU.

Issue still persistent for dGPU staying at extremely low wattage and clock speed, between 0-9w and 0-500ish Mhz
Applications run on the dGPU explicitly still crash consistently.

Beefy Joe · 2024-10-27 08:21:28

amdgpu.dcdebugmask=0x10
amdgpu.dpm=1
amdgpu.ppfeaturemask=0xffffffff
amdgpu.dc=1
amdgpu.si_support=1
amdgpu.cik_support=1

Adding all of these flags to the boot parameters seems to have fixed all issues I was having. Some of these are probobly unnessary and not needed, but I had gotten frustrated and just started throwing paremeters into my linux.config to see what would stick.
At this time I have 165hz refresh rate on the laptop screen, and games launch on the dGPU now while in hybrid mode.
In AsusMuxDgpu mode, the system is now responsive, no screen artifacting, and there is no iGPU used when playing games.

Weirdly Steam still needs 'PrefersNonDefaultGPU=false' in the steam.desktop file but I set 'X-KDE-RunOnDiscreteGpu=true'. Settng PrefersNonDefaultGPU to true, results in never ending loop of steam crashing until the process is killed, this is a steam issue I guess.
In steam, setting 'DRI_PRIME=1 %command%' for launch arguments makes games run on the dGPU as expected now.

I am going to mark this as Solved.
I will probobly start removing boot parameters one by one and see which ones are actually needed.
Hope this helps someone else.

seth · 2024-10-27 13:05:34

* amdgpu.dcdebugmask=0x10
DC_DISABLE_PSR

* amdgpu.dpm=1
Default, setting it to "0" will likely make the boot fail

* amdgpu.ppfeaturemask=0xffffffff
default

* amdgpu.dc=1
default for all modern™ GPUs

* amdgpu.si_support=1
* amdgpu.cik_support=1
You don't have relevant (older) GPUs, those do nothing.

Arch Linux

#1 2024-10-26 23:34:04

[Solved]dGPU stuck at 0Mhz, Not Detected by supergfxctl, apps using dG

#2 2024-10-27 06:16:31

Re: [Solved]dGPU stuck at 0Mhz, Not Detected by supergfxctl, apps using dG

#3 2024-10-27 08:21:28

Re: [Solved]dGPU stuck at 0Mhz, Not Detected by supergfxctl, apps using dG

#4 2024-10-27 13:05:34

Re: [Solved]dGPU stuck at 0Mhz, Not Detected by supergfxctl, apps using dG

Board footer