Update: This does not appear to happen under KDE wayland

It also does not happen on XFCE nor lxqt. I tried openbox/KDE and the problem happened there.

Please attach the corresponding dmesg output and Xorg log file.

Created attachment 134180 [details]
The Dmesg output

Created attachment 134181 [details]
Current Xorg log

Created attachment 134182 [details]
Output of journalctl -k

Thought I'd add this for good measure.

Looks like a display related issue in the kernel driver. Any chance you can try an amd-staging kernel with DC enabled, to see if it happens with that as well?

Sure, could you link me directly to the one you wanted me to try?

I went looking for them and noticed that these are all made for ubuntu. Will they still work with Manjaro?

I managed to get Kernel 4.12 of amd-staging working and the problem still persists.

The problem also happens in Kernel 4.13.2. Although it does not seem as bad.

Created attachment 134285 [details]
New Xorg Log

I'm curious if you only see this with Stardew Valley? I've seen reports of people having the same issue with Stardew Valley independent of their graphics adapter. Seems to be a combination of game and window manager.

https://steamcommunity.com/app/413150/discussions/1/405693392918042081/
https://steamcommunity.com/app/413150/discussions/1/333656722968187453/

No, I see this in other games too. Antichamber and Torchlight II come to mind.

Oh, I should also mention that it is not only in games that I see this flickering. It happens in firefox, and when switching activities in KDE sometimes.

I tested under other Desktop Environments, and it does appear that the problem is still there, just not as noticeable as under plasma. I do want to know though, is there any work I can do that would help someone to debug?

The problem seems to have gotten better within the last month, but is still not solved.

I have tried using a different monitor and also using a DVI cable. Neither of these mitigated the problem in any way. I also tried setting the resolution of the monitor to 720p, which interestingly did help the problem quite a bit. Still did not solve it, unfortunately, but I hope when someone sees this it will give them a better idea of what they're dealing with.

I figured it out, Since the power profile in dri was set to auto, it keeps switching between the maximum and minimum clock speeds.

Looks like some guys more familiar with the power profiles should take a peek at this. Not really familiar with that myself.

Can you post a video of the flickering? The one linked above no longer works.  Is it like tearing or does the display go blank or unstable image?

Hi, sorry I took so long. I usually check this around once a month. I reuploaded my gameplay on youtube. https://www.youtube.com/watch?v=-uPHG8mz4Xc&feature=youtu.be  

This happens in every game, and on the desktop if I don't set my power profile manually to high. Auto and low exhibit buggy behavior, with low being far worse than auto.

Hello!

I am having a similar (same?) issue on my RX580 (Asus STRIX TOC).
Seems to be an issue with MCLK switching.


Here is a video of it happening on the desktop:
https://www.youtube.com/edit?o=U&video_id=z28fFqNdjAY
(there is also screen flickering that's not seen on camera, but it doesn't happen too often in contrary to the horizontal lines)

OBS is unable to campture the glitches though:
https://www.youtube.com/edit?o=U&video_id=iMEnprhBKFQ

Notes: 
1) Most of the time glitches happen when something new gets rendered. 
2) Google Chrome/Chromium always glitch (to a lesser extent when only the start page is open and nothing changes on the screen, opening Facebook guarantees glitches).
3) Playing video in VLC doesn't cause any glitches (x264 encoded MKV).
4) It's really easy to reproduce by setting the power profile to low (which fixes the issue) and then switching to high while looking at the screen. The glitch will occur for a split second. Switching from high to low also causes the issue.

Workarounds so far:
1) Recompiling the kernel with "smu7_vblank_too_short" forced to output true (aka disabling MCLK switching) fixes the problem but locks the MCLK at 2Ghz and causes coil whine and higher temps.
2) Setting the power profile to anything but "auto".
3) Disabling DC.

It's also worth noting that in my case "low" power profile works fine, but R9 390x users seem to need "high" power profile to fix it (from the "smu7_vblank_too_short" thread: https://bugs.freedesktop.org/show_bug.cgi?id=96868#c32).

I can test any patches/programs/cases if you need it.

Created attachment 137789 [details]
dmesg log (maximum verbosity) RX580

Seems like this is a regression actually. I've managed bisect the commit which caused the problems.

Last working commit: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.15-dc&id=8ee5702afdd48b5864c46418ad310d6a23c8e9ab

Breaking commit: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.15-dc&id=b9e56e41e0c55c2b2ab5919c5e167faa4200b083

Keep in mind that you need https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.15-dc&id=9ba29fcb76a559078491adffc74f66bf92b9dbea commit to be able to compile the kernel, but judging by the changes the merge commit was the one that broke it.

Some more details:

1) Disabling/enabling FreeSync doesn't matter
2) Issue happens under Xorg KDE/Wayland Gnome/Xorg GNOME
3) HDMI or DP doesn't matter


I'd try to narrow it down to the exact part of the commit that causes the issue, but I am having an issue with my Ryzen soft locking thread by thread until a complete lockup happens when compiling with 16 threads.

That regression commit is the one that introduced the new DC display driver, so going back to the last working commit will effectively be the same as disabling DC for you.

Hmm.

I guess I got deceived by `CONFIG_DRM_AMD_DC=y` being available in that commit and logs like `dc_link_detect` and `dc_link_handle_hpd_rx_irq` that didn't show up before.

Sorry about that!