AMD Sends In Their Initial AMDGPU Driver Updates For Linux 5.2

[Jabberwocky]

The reason this normally happens is that if memory clock (and actual GDDR voltage, but this isn't exposed) remained at the lowest state when two monitors are plugged in and enabled, intense flickering could occur depending on the monitor frequency and resolution (typically when the displays have different resolution and/or timings) - this is exactly what happens when the overclocking flag is enabled with the appropriate amdgpu.ppfeaturemask flags, on my Sapphire Nitro+ RX480, when using a 1920x1080 60 Hz and a 1920x1200 60 Hz display at the same time: there, for some inexplicable reason (likely a bug), normal automatic mclk selection behavior does not occur as with overclocking disabled and users are forced to micromanage it when connecting/disconnecting a secondary monitor.

I had (not so intense) flickering issues on my ultrawide monitor, the problems went away when I replaced my displayport cable. IIRC there is no ack on the display output protocol so it's difficult to determine exact cause. In my case the bandwidth used was way below the displayport spec of my screen/GPU (also nitro+ rx480) and cables are generic I am left to believe that it was a faulty/damaged cable.

Does the auto-off fan feature work in your case by the way? On my RX480 it does only on Windows, and on Linux I have to use a script to manage it depending on temperature (this one to be specific). However that sort of simple temperature-dependent fan curve tends to be noisier in general (when fans are active) than the built-in fuzzy-logic fan control behavior.

Exactly the same as you described. The second that I pass my GPU through to KVM (windows) then auto-off fan kicks in . It does not work on Linux without manual configuration. One can also configure the profiles in the GPU BIOS if you really wanted. That said I've been holding back kernel updates for a couple of months now.

[skeevy420]

Put amdgpu.ppfeaturemask=0xfffd7fff to the kernel command line to make the powerplay work at 4k60Hz with RX570 and maybe others.




What you do with amdgpu.vm_update_mode, "The default is -1 (Only in large BAR(LB) systems Compute VM tables will be updated by CPU, otherwise 0, never)."

The intel dgpu will be buggy as hell, nobody has resources to test everything and it is the first fast intel dgpu.

That's the one wattmanGTK suggests for my RX 580 4GB.

[skeevy420]

Huh? I'm on Arch Linux and I have the latest packages of the kernel, mesa and LLVM, I even tried mesa-git and AMD wip kernel. I still get frequent corruption/quirks with glamor, I'm not sure how you can claim that.

Night before last on Manjaro I discovered that a combination of Linux 5.0.3 to 5.0.5, Mesa 18.3.4, Plasma 5.15.3, and SMPlayer using vdpau would trigger massive screen corruption with my 580 (with and without an undervolt) if I leave a video paused and the screen blanks. Until that bug came up, I had the same experiences as debianxfce. Its happened to me three times at random since the Plasma 5.15.3 update. I have a few more custom things I'd like to revert before I'd call it an official Plasma bug and actually report it.

[atomsymbol]

The issue is that switching power modes needs some time and is normally done during vblank, when no data has to be send to the screen. With higher frequency the vblank time is shorter (My 290 stays in full memory clocks when I set over 120 Hz on my monitor). And with multiple monitors I guess the vblank is not synced?! In that case the monitor could start to flicker when the power switching is still ongoing and no data send to the monitor in time. So the drivers go in permanent higher clock speed mode to prevent this flickering.

R9 290 has 320GB/s of memory bandwidth, with lower mclk it is 32GB/s if I am correct. Assuming a 4K monitor, 3840*2160*4*120 = 4GB/s. In theory, the lower mclk has enough bandwidth to feed multiple 4K 120Hz displays. In practice, it may not be enough due to memory contention and overheads, so testing is needed to tell whether it works.

[atomsymbol]

Does the auto-off fan feature work in your case by the way? On my RX480 it does only on Windows, and on Linux I have to use a script to manage it depending on temperature (this one to be specific). However that sort of simple temperature-dependent fan curve tends to be noisier in general (when fans are active) than the built-in fuzzy-logic fan control behavior.

Auto-off fan feature works in Linux in my case (R9 390).

amdgpu-fancontrol: Nice.

[aufkrawall]

Please file a bug report for this, we need to make as much noise as we can, otherwise they will not fix anything. The developers act like amdgpu is perfect, and it clearly isn't.

Not true, you very quickly get feedback on amdgpu DDX bugtracker (and fixes too).

[jrch2k8]

Ah good question. It's only happening for me under X. The 'random garbage rendering' happens every new gtk3 window. The partially-rendered textview content happens semi-regularly. I've just tested for about 5 minutes under Wayland, and can't trigger either of these bugs.

As for the modesetting DDX - what GPU are you using? If you use modesetting for AMD, I believe you lose features, and I'm not sure what the 3D acceleration situation would be. I used to use the modesetting driver when I had an Intel GPU - and it ( and therefore glamor ) certainly worked well in that setup. This is definitely an AMD driver issue ... but as I've just discovered, only under X.

I'd switch to wayland now if I could, but I'm still having 2 major issues:

• gtk3 menu rendering issues - the 1st menu pop-up is placed partially off-screen, and subsequent pop-ups appear empty
• compositor crashes kill all X clients

As I'm developing a gtk3 app that uses menus to navigate between windows, the 1st point is a deal-breaker for me. Oh and the 2nd point is also a deal-breaker for me. Other than these 2 issues, I can see already that Wayland ( this is under Enlightenment, by the way ) is much faster and smoother. Looking forward to it all coming together

Archlinux here:
using lcarlier repo for latest everything mesa related
Gnome 3.32

AMD HD 7700 1GB with an AMD FX 6100: X or Wayland no corruption(using amdgpu not radeon driver)
AMD RX 470 8GB with a Xeon E3-1231V3: X or Wayland no corruption

DDX used xf86-video-amdgpu-git

[Kraut]

R9 290 has 320GB/s of memory bandwidth, with lower mclk it is 32GB/s if I am correct. Assuming a 4K monitor, 3840*2160*4*120 = 4GB/s. In theory, the lower mclk has enough bandwidth to feed multiple 4K 120Hz displays. In practice, it may not be enough due to memory contention and overheads, so testing is needed to tell whether it works.

This is not about bandwidth. This is about the constant time it takes for the power mode (at last for vram) to switch. If your monitors vblank period is shorter then that you can get flickering each time the power mode changes.

[pixo]

As for the modesetting DDX - what GPU are you using? If you use modesetting for AMD, I believe you lose features, and I'm not sure what the 3D acceleration situation would be. I used to use the modesetting driver when I had an Intel GPU - and it ( and therefore glamor ) certainly worked well in that setup. This is definitely an AMD driver issue ... but as I've just discovered, only under X.

Adaptive-sync is not supported by modesetting DDX but that is all i am aware of.
Patched xserver using modesetting DDX can use DRM leases for multiseat with hw acceleration for every seat via 1 GPU.
That does not work for amdgpu DDX and I could not make it work. Will give it another shot this weekend.

[MrCooper]

I've seen the same on my new Ryzen / Vega 10 laptop. New gtk3 windows briefly render a window full of garbage before behaving properly. I'm also seeing rendering glitches in gtktextview and gtksourceview widgets, which is fixed when I drag-select the content.

Like https://bugs.freedesktop.org/110214 ?

Not sure if it's been reported, but it's hard to see how they wouldn't be aware of it ...

If something isn't reported, the default assumption has to be nobody else is aware of it.

Are you also using Arch Linux? Is anyone using a different distro seeing these issues? Just to be clear, I'm not trying to blame it on Arch, just narrowing down the circumstances, as it's not happening for everybody. I wonder if it might be related to building xserver with meson, not sure any distro other than Arch is doing that yet.