AMDGPU Kernel Driver Is Working Out Well On Linux 5.0

[clapbr]

Flickering means that there is not enough power to drive displays.

Nope. Flickering can happen for many reasons but in this case it's the amdgpu trying to change mclk at the wrong time. In Alex Deucher words:

Memory reclocking has to happen during the vblank period to avoid flickering.

Pro gamers use single monitor and there is no advantage of dual screens.

Pro gamers (people who compete and earn money playing games) don't use Linux. Almost every big streamer (people who make money playing games, thus also "pro gamers") uses multiscreen setups.

Also Michael uses ubuntu that is more stable and maybe lighter for the GPU than fedora.

nope, that's just your assumption

See, no sense to compile Mesa by yourself. I have been using freesync over a month: https://www.youtube.com/watch?v=lGesNjhUo-w

You should use Debian packages with Debian. Debian packages are easy to update and remove. They are designed to work together.

There are a lot of reasons to compile mesa by yourself. Native gcc optimizations, including/removing specific drivers, using out-of-tree patches (I had freesync long before you got it in oibaf) etc. It's not that difficult to build it in to a deb package anyway, but that is one of the reasons me and others use Arch-based distros (PKGBUILDs are perfect for stuff like this). Stop assuming your setup is the best for everyone and only then you might have a chance to stop making yourself a fool for people with a clue of what they're doing.

No changes in the idle governor. The CPU frequency governor slows down and is an optional feature of the Linux kernel so remove it. Using the Bios is a better way to control CPU power and fans. Power consumption depends of your other hardware too.

If you read the code and docs you'll see there is no difference between "performance" governor and removing governor completely. Both let the bios control frequencies directly.

[Venemo]

There is a bug with RX570 and 4K60Hz resolution that the dynamic powerplay feature is disabled and the engine clock is fixed to 1200Mhz. The fix for this is to use the kernel command line parameter amdgpu.ppfeaturemask=0xfffd7fff. You could try that too.

With a single 4K 60Hz monitor there is no bug.
With two 4K 60Hz monitors, the fix is to boot with amdgpu.ppfeaturemask=0xffffffff and manually set the shader and memory clocks on the GPU with:

echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level
echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk
echo "5 6 7" > /sys/class/drm/card0/device/pp_dpm_sclk

Also Michael uses ubuntu that is more stable and maybe lighter for the GPU than fedora.

Why? Both of them use Gnome 3.

Flickering means that there is not enough power to drive displays.

No, it means that the GPU clock is set improperly, as explained by clapbr

[aufkrawall]

It is something that can be worked around by manually setting the GPU clocks, see the linked bugreport for details.

I just said that. Btw. it should suffice to enforce maximum VRAM pstate and not touching pstates for the GPU itself.

And yes it can be fixed: the amdgpu driver should by itself figure out the correct clock.

I think this isn't a hardware defect, but if it is, the driver should still workaround it by setting the correct clock.

That's not a real fix. Polaris already has this problem with 75Hz single display, while neither Vega nor other GPU vendors do.

[Grogan]

That's good to hear, I got kernel shy with Linux 4.19... the amdgpu driver was failing on the ring buffer test while initializing DRM (R9 380/Volcanic Islands Tonga). I've been sticking with 4.18.20 since that and haven't revisited it (though I heard it's been fixed).

[Venemo]

I just said that. Btw. it should suffice to enforce maximum VRAM pstate and not touching pstates for the GPU itself.
That's not a real fix. Polaris already has this problem with 75Hz single display, while neither Vega nor other GPU vendors do.

As a user, I don't care what the driver does, just that it shouldn't flicker my displays is all.

[Haxk20]

vrr_capable=0 means that it is not supported
Missing the parameter with eDP means that there is no support in the driver or hardware. With RX570:

DisplayPort-0 connected 3840x2160+0+0
vrr_capable: 1
HDMI-A-0 disconnected
vrr_capable: 0
DVI-D-0 disconnected
no vrr_capable variable available

VEGA 8 has support for freesync as people got it working on this exact laptop on windows with little EDID edit which i will do on linux too.
vrr_capable on HDMI is because there is nothing connected to it.
Maybe its the initial implementation that doesnt have support for iGPU i guess.
I hope i will get it working because freesync can help here a looot

[dwagner]

I wish I could agree to the article's statement, but I cannot. It still only takes me minutes to reproduce the crash bug reported in https://bugs.freedesktop.org/show_bug.cgi?id=102322" on the latest git head version, a bug that has haunted amdgpu for about 18 months now.

And as I already mentioned in another thread, there is a power usage regression in 5.0, again, with weird minimum clocks indicating that dynamic power management is still acting randomly:

> cd /sys/class/drm/card0/device

> xrandr --output HDMI-A-0 --mode 3840x2160 --rate 30
> echo manual >power_dpm_force_performance_level
> echo 0 >pp_dpm_mclk
> echo 0 >pp_dpm_sclk
> grep -H \\* pp_dpm_mclk pp_dpm_sclk
pp_dpm_mclk:0: 300Mhz *
pp_dpm_sclk:0: 214Mhz *

> xrandr --output HDMI-A-0 --mode 3840x2160 --rate 50
> echo manual >power_dpm_force_performance_level
> echo 0 >pp_dpm_mclk
> echo 0 >pp_dpm_sclk
> grep -H \\* pp_dpm_mclk pp_dpm_sclk
pp_dpm_mclk:1: 1750Mhz *
pp_dpm_sclk:1: 481Mhz *

> xrandr --output HDMI-A-0 --mode 3840x2160 --rate 60
> echo manual >power_dpm_force_performance_level
> echo 0 >pp_dpm_mclk
> echo 0 >pp_dpm_sclk
> grep -H \\* pp_dpm_mclk pp_dpm_sclk
pp_dpm_mclk:0: 300Mhz *
pp_dpm_sclk:6: 1180Mhz *

[tuxd3v]

No changes in the idle governor. The CPU frequency governor slows down and is an optional feature of the Linux kernel so remove it. Using the Bios is a better way to control CPU power and fans. Power consumption depends of your other hardware too.

Indeed, but what I was talking about is the Power draw for each power profile..
In Linux is like crazy, on that mater..

On Windows for example, there are better tunned profiles, and the AMD cards consume less power than in Linux, exactly because of the Power profiles..
This for me should be one of the next key steps, for AMD,
Because it doesn´t mater if your driver is more performant, if it his consuming tons of power, then the "Better Driver", is something difficult to classify..
A 2 step way is needed like a loop, on each iteration
1. Features
2. Optimization

[Haxk20]

vrr_capable=0 means that it is not supported
Missing the parameter with eDP means that there is no support in the driver or hardware. With RX570:

DisplayPort-0 connected 3840x2160+0+0
vrr_capable: 1
HDMI-A-0 disconnected
vrr_capable: 0
DVI-D-0 disconnected
no vrr_capable variable available

issue has been fixed. it was a bug. i know my VEGA 8 in ryzen 5 2500U supports it and rx560x does too so it must be supported on linux too. reported it and its fixed now.

[ernstp]

Rebooted. Getting vrr_capable in xrandr, but I though there should be an vrr_enabled entry as well but there's not. Glxinfo is reporting Mesa 19.0-git as expected(

The patch series went through quite a few iterations where properties came and went, I think that property was removed in the end and the Xorg.conf setting was added.