Graphical artifacts on AMDGPU after recent tumbleweed update

I updated Tumbleweed yesterday and following the update I began to experience flickering graphical artifacts. I’m using AMDGPU with RX 480 card and KDE.

I tried to capture a screenshot without luck, but basically there’s a scrambled multi-colored flickering in certain areas such as when a notification pops up or when I open a dropdown in firefox. The entire affected content area is covered with this scrambled multi-colored bars rather than the actual content, until I cause the display to refresh somehow.

I turned the hardware acceleration off in Firefox which resolved the issue in Firefox specifically but not across KDE obviously.

Is there a way to turn hardware acceleration off across Xorg? Is this a known bug that just cropped up or do I have failing hardware or … ?

I have a Mullins R5, I have TearFree enabled though and run the GNOME DE, no issues like this seen so far.

Yeah this isn’t just tearing, it’s fairly large regions of the display which are getting corrupt until a refresh it triggered (like dragging a window over top). I’ll try to capture a video.

I do have Fedora 25 installed with Gnome on the same machine also using amdgpu, and don’t experience this issue, so I’m inclined to think it’s a bug or configuration issue.

Yes, I get that too, but with the radeon stack when used with glamor. exa renders properly whatever it is that the Plasma/Qt window stuff is asking to be done. You don’t have that choice with the amdgpu xorg driver (its glamor or its shadowfb/cpu). glamor gets the rendering done by translating requests into openGL and having the 3D part do it. Not everything translates well and can be slow. In other cases, such as this, something buggy is happening in the chain.

If its bothering you a lot, set the AccelMethod in the Device snippet file (/etc/X11/xorg.conf.d) to none. See man amdgpu for details.

When TW finally gets updated to xorg server v1.19, there are a lot of changes that affect glamor, and hopefully this issue will be taken care of, so you might wish to comment out any AccelMethod option you introduce and re-visit your experience utilizing glamor … if not (i.e. future testing reveals the same rendering glitches while utilising glamor), then hopefully a Plasma side update resolves the issue.

Cool, I didn’t see the AccelMethod setting. I’ll give that a shot soon. I wonder why this just introduced itself after the last update, though? Maybe a new configuration change was applied during the update.

I don’t think it is a configuration change. I see a couple of likely vectors in which a change occurred that draws out this unintended rendering result:

  • something in the amdgpu DDX
  • something in glamor … glamor is embedded in the xorg server, and given I’m waiting upon that update, so I know this isn’t what got updated
  • somehting in the 3D side (radeonsi)
  • something in Plasma

Just to add – whatever the change, it need not even be a regression. Crude Hypothetical example:

  • Important graphics unit Zorg is programmed (incorrectly) that 3+3 = 7
  • Supercool Window Manager is also programmed incorrectly that 3+3 =7
  • Unintentionally, the two wrongly programmed pieces coexist quite happily
  • during latest release cycle, developer of Supercool Window Manager spots logic error and corrects faulty code … for WM, 3+3 = 6 now
  • Important graphics unit Zorg and Supercool Window Manager no longer see eye to eye, and “observable bug” occurs

I follow ya. Somehow I was under the impression that you were experiencing this all along with this card yet for me it had just started.

I tried adding

Option "AccelMethod" "none"

to the device section, but it caused a segmentation fault during boot when Xorg was starting, and just ended up in a never ending loop of trying to start the X server.

Does disabling the compositing in Plasma help?

Well, I’m using a different AMD device and different driver stack (radeon). But the glitching only began when I switched (from using exa) to using glamor Accel. It was generally minor at first. However, likely the same time as you reported this last week, I had noticed an intensification in the glitching. That said, I’ve since pulled in v1.19 of the X server, and the glitching, while still present, is much reduced (as I had hoped and anticipated it would be, given the improvements to glamor).

I don’t recall if the Modesetting/glamor combo produces the same glitching for me on my hardware, though I don’t suspect it would be any different (I will test it out in the near future again).

I tried adding

Option "AccelMethod" "none"

to the device section, but it caused a segmentation fault during boot when Xorg was starting, and just ended up in a never ending loop of trying to start the X server.
Well, that’s unfortunate.

But you have probably also now pulled in v1.19 of X, so I’d be curious if you’re still expereincing these artifacts, and, if so, if there has been any noticeable change.

Does disabling the compositing in Plasma help?

It does not appear to make any difference.

I’m still experiencing the artifacts on 1.19.1. Perhaps it isn’t as bad but it is definitely still ocurring.

Yeah, I agree. And, actually, I’ve noticed it get worse over the last couple of days, particularly with Firefox … Gonna have to try out FF’s rendering options

It goes away in firefox if I turn off hardware acceleration in firefox… and Firefox does seem to cause the most issues.

I think I have fixed this by removing the TearFree option from the device in the X11 conf files (I had previously added this manually to stop tearing). I don’t have tearing even with this option removed, and the flickering seems to have gone away.

I get plenty of the glitches when resizing windows of other apps (like dolphin, Libreoffice, audacity, … ) … the during the window resizing, you get a macroblocked image (either of the application window or the underlining desktop background, or an image that you viewed recently but was still held in vram).

I just happen to use FF more, and so notice all its glitching more then I do with the others.

Tearfree (enabled or disabled) has no affect upon this for me.

I’m not going to bother changing FF’s rendering and wil stick with the defaults. IIRC, FF51 is supposed to bring in another change to accelerated layers, so will see what that brings.