amd_performance_level does not get set

[zany130]

Describe the bug whatever value you put in amd_performance_level in the GPU section is ignored. This is with amdgpu.ppfeaturemask=0xffffffff set a as a kernel argument which used to fix the issue

To Reproduce Steps used to reproduce the behavior:

1. add amdgpu.ppfeaturemask=0xffffffff to your boot args
2. create /etc/gamemode.ini if it does not exist with the following in it:

[gpu]
; Setting this to the keyphrase "accept-responsibility" will allow gamemode to apply GPU optimisations such as overclocks
apply_gpu_optimisations=accept-responsibility

; The DRM device number on the system (usually 0), ie. the number in /sys/class/drm/card0/
gpu_device=0

amd_performance_level=high

3. Launch gamemod with gamemoderun mangohud vkcube
4. View output of cat /sys/class/drm/card0/device/power_dpm_force_performance_level
5. See a different value from what was expected

Expected behavior cat /sys/class/drm/card0/device/power_dpm_force_performance_level to show the value put in the game mode ini

System Info (please complete the following information):

• OS and version: Garuda Linux
• GameMode Version 1.7

[Madouura]

Do you have corectrl or something like it running? It's power settings may be conflicting with gamemode.

[zany130]

No i specifically disabled corectrl from running when i use gamemode to configure the GPU

[nfp0]

I also have this problem now. It used to work right, but now it does not set the power_dpm_force_performance_level. When I run gamemoded --testI get this:

ERROR: Current AMD GPU performance level during gamemode does not match requested value!
        expected:high was:auto

EDIT: I don't have corectrl or anything like it installed.

[Calinou]

Duplicate of https://github.com/FeralInteractive/gamemode/issues/307.

[zany130]

i thought i was running into a different issue since the kernal parameters no longer fixes this issue it used to work on older versions of gamemode

[nfp0]

@Calinou That other issue should be closed. It does not specify if setting the kernel parameter fixes it or not. This new issue is about it not working even with the kernel parameter set. It only showed up recently. It was working before.

@zany130 Please specify on the OP that this is failing even with the kernel parameter set.

[Calinou]

It may be worth checking which configuration file is being read too: https://github.com/FeralInteractive/gamemode/issues/307#issuecomment-1278267172

I'd argue that changing the power profile (≠ overclocking) should not be locked like this, but that's just me :slightly_smiling_face:

[nfp0]

I'd argue that changing the power profile (≠ overclocking) should not be locked like this, but that's just me

@Calinou Completely agree. I've answered you there, by the way.

[nfp0]

It seems restarting the gamemoded daemon fixes the problem. It's even working without needing any kernel parameter. At boot I get this error message on the daemon log:

ERROR: Couldn't open vendor file at /sys/class/drm/card0/device/vendor, will not apply gpu optimisations!
ERROR: Found invalid vendor, will not apply optimisations!
ERROR: Couldn't open vendor file at /sys/class/drm/card0/device/vendor, will not apply gpu optimisations!
ERROR: Found invalid vendor, will not apply optimisations!

Yes, it shows up 2 times. After I restart the service, no error messages show up and it works as expected.

This led me to believe that gamemoded is starting too early. And I found out why it's happening in my case. I have a systemd unit that looks like this:

[Unit]
Description=TTY session

# Make sure we are started after logins are permitted.
After=graphical.target

[Service]
Type=simple
ExecStart=/usr/bin/systemctl --wait --user start tty-session-nuno.target

# The user to run the session as. Pick one!
User=nfp0
#Group=group

# Set up a full user session for the user, required by Weston.
PAMName=login

# A virtual terminal is needed.
TTYPath=/dev/tty5
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes

# Log this user with utmp, letting it show up with commands 'w' and 'who'.
UtmpIdentifier=tty5
UtmpMode=user

[Install]
WantedBy=graphical.target

This is to be able to start a Weston or KDE Wayland session from ssh, but that's beside the point.

When this is enabled, Gamemode presents the error I've shown previously, saying it can't read /sys/class/drm/card0/device/vendor. But if I disable this unit, Gamemode works as normal. I think this is causing the Gamemode user unit to start too early before it has access to that file. But I can't understand why.

[nfp0]

Interesting. Even though gamemode seems to be now working as expected on my system, with all tests from gamemoded --test succeeding, I've noticed that sometimes only the memory clocks get maxed out while the shader clock stays low. This is true most times I run gamemoderun vkcube, but not always. On the other hand, when I run gamemoderun retroarch, the shader clocks jump to max. But again, not always.

I've verified this behavior happens outside of gamemode, even by setting echo "high" > /sys/class/drm/card0/device/power_dpm_force_performance_level manually. I don't know why this happens and the behavior seems erratic, but it looks more like a driver issue than gamemode's.

@zany130 Your situation looks different though, as the value on power_dpm_force_performance_level seems to be ignored. Could you please show us the output of journalctl --user -u gamemoded -b after triggering the first failure?