Created attachment 144944 [details]
moment of performance drop

I have the same laptop so I tried it and there is actually an interesting effect, see attached screenshot.

At first performance is quite good, but at some point during the benchmark, performance and GPU usage suddenly drops a lot.

The performance then stays low permanently, even when restarting the benchmark, after waiting for the dgpu get shutdown by runpm.

Maybe I'll take a closer look later with more gallium hud graphs and maybe umr --top, but for now I'll just leave a comment here confirming that there is an issue.

Also loading the benchmark seems to take much longer after the performance drop happens, which seems very suspicious.

Tested on Arch with mesa 19.1.3, Linux 5.1, 5.2 and 5.3-rc2. Happens on all three kernel versions.

On the Arch you have more fps then Ubuntu, probably Kernel 5.1 better then 5.0.

Just now update Kernel to 5.0.0-23-generic, it seems nothing change, same 26-27 fps on basic preset.

Christoph Haag, do you know the developers planning some update for amdgpu driver?

Created attachment 144945 [details]
Windows 10 test - 64 fps

Just for comparison. 
Same laptop, same test, but running on Windows 10. I have got around 64 fps...

The performance drop may be related to an incorrect boost frequency (400MHz), compare here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1830522

Workaround is to set
echo 0 > /sys/devices/system/cpu/cpufreq/boost

On multi-core cpus, better use the performance cpu freq governor.
Some load profiles may be badly managed by the on-demand cpu freq governor.
Due to the load profile, some cores may not get enough load to be switched to
their highest frequencies (which is critical for realtime game performance).

I did notice significant fps loss with the on-demand cpu governor with some of
my dota2 configurations running on a 8-cores 4.7GHz (FX9590).

This is a pb for lambda users who don't want to know anything about cpu freq
governors.

Multi-threaded games must be aware of the pb and warn the users about the
cpu governor settings (this is true on any OS).

I have a similar laptop (TUF Gaming FX505DY), and the very same problem, with kernel 5.3.7 and governor set to 'performance'.

When I run a game with DRI_PRIME=1 (to use the dedicated GPU) the system gets throttled down at some point and never recovers. Every CPU core runs at 400Mhz which makes the system practically unusable until reboot.

I have tried kernel 5.4-rc5 – that did not help.

Disabling cpufreq boost (echo 0 > /sys/devices/system/cpu/cpufreq/boost) stops the drastic slowdown from happening, but this also makes the system significantly slower than normal (still much better than after the bug appears), so there is no gain from using the discrete GPU (DRI_PRIME=1).

I wonder if this might be the problem:

> $ cat /sys/class/hwmon/hwmon3/{name,temp1_crit,temp1_crit_hyst}
> amdgpu
> 94000
> -273150
> $ cat /sys/class/hwmon/hwmon4/{name,temp1_crit,temp1_crit_hyst}
> amdgpu
> 80000
> 0

Are these hysteresis values being used? If so, then those values won't work for recovering from thermal throttle. Though, I have never seen temperature reading reaching 80 degrees there.

The first one seems to be the discrete GPU (RX560X), the other one integrated (Vega 8).

Looks like it is not amdgpu bug, but a faulty cooling algorithm implemented in BIOS/hardware (reportedly the same happens on Windows before dedicated ASUS software is installed).

I was able to make things much better with custom thermald config, but Linux is still lacking proper tools to do it right.

It is quite tricky, probably mostly due to interaction between the GPU heating and the CPU boost feature not accounting for the extra heat.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/882.