https://bugs.freedesktop.org/show_bug.cgi?id=102646
Bug ID: 102646 Summary: Screen flickering under amdgpu-experimental (buffer corruptions?) Product: Mesa Version: 17.1 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: katoflip@protonmail.com QA Contact: dri-devel@lists.freedesktop.org
GPU/Stack: R9 390x/amdgpu-experimental/xf86-video-amdgpu/radeonsi CPU: R7 1700x Distro/Kernel: Manjaro/4.12.11 Display: ASUS VG248QE 144hz. Desktop Environment: KDE
Under games and on the desktop(occasionally) there is screen flickering.
Example: https://vid.me/n0t1r (sorry for audio/video, OBS is unable to capture the flickering)
This happens at every screen frequency that I am capable of achieving (60-144hz), on HDMI and Display Port. I have tried all sorts of Vsync options, and the Compton compositor. However, none of those worked.
Let me know what other information you want.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Justin Mitzel katoflip@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #1 from Justin Mitzel katoflip@protonmail.com --- Update: This does not appear to happen under KDE wayland
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #2 from Justin Mitzel katoflip@protonmail.com --- It also does not happen on XFCE nor lxqt. I tried openbox/KDE and the problem happened there.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #3 from Michel Dänzer michel@daenzer.net --- Please attach the corresponding dmesg output and Xorg log file.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #4 from Justin Mitzel katoflip@protonmail.com --- Created attachment 134180 --> https://bugs.freedesktop.org/attachment.cgi?id=134180&action=edit The Dmesg output
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #5 from Justin Mitzel katoflip@protonmail.com --- Created attachment 134181 --> https://bugs.freedesktop.org/attachment.cgi?id=134181&action=edit Current Xorg log
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #6 from Justin Mitzel katoflip@protonmail.com --- Created attachment 134182 --> https://bugs.freedesktop.org/attachment.cgi?id=134182&action=edit Output of journalctl -k
Thought I'd add this for good measure.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #134181|text/x-log |text/plain mime type| |
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Product|Mesa |DRI Version|17.1 |unspecified QA Contact|dri-devel@lists.freedesktop | |.org | Component|Drivers/Gallium/radeonsi |DRM/AMDgpu
--- Comment #7 from Michel Dänzer michel@daenzer.net --- 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?
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #8 from Justin Mitzel katoflip@protonmail.com --- Sure, could you link me directly to the one you wanted me to try?
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #9 from Justin Mitzel katoflip@protonmail.com --- I went looking for them and noticed that these are all made for ubuntu. Will they still work with Manjaro?
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #10 from Justin Mitzel katoflip@protonmail.com --- I managed to get Kernel 4.12 of amd-staging working and the problem still persists.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #11 from Justin Mitzel katoflip@protonmail.com --- The problem also happens in Kernel 4.13.2. Although it does not seem as bad.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #12 from Justin Mitzel katoflip@protonmail.com --- Created attachment 134285 --> https://bugs.freedesktop.org/attachment.cgi?id=134285&action=edit New Xorg Log
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #13 from Harry Wentland harry.wentland@amd.com --- 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/
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #14 from Justin Mitzel katoflip@protonmail.com --- No, I see this in other games too. Antichamber and Torchlight II come to mind.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #15 from Justin Mitzel katoflip@protonmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #16 from Justin Mitzel katoflip@protonmail.com --- 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?
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #17 from Justin Mitzel katoflip@protonmail.com --- The problem seems to have gotten better within the last month, but is still not solved.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #18 from Justin Mitzel katoflip@protonmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Justin Mitzel katoflip@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Screen flickering under |Screen flickering under |amdgpu-experimental (buffer |amdgpu-experimental [buggy |corruptions?) |auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Justin Mitzel katoflip@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Screen flickering under |[dc] Screen flickering |amdgpu-experimental [buggy |under amdgpu-experimental |auto power profile] |[buggy auto power profile]
--- Comment #19 from Justin Mitzel katoflip@protonmail.com --- I figured it out, Since the power profile in dri was set to auto, it keeps switching between the maximum and minimum clock speeds.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #20 from Harry Wentland harry.wentland@amd.com --- Looks like some guys more familiar with the power profiles should take a peek at this. Not really familiar with that myself.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #21 from Alex Deucher alexdeucher@gmail.com --- 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?
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #22 from Justin Mitzel katoflip@protonmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #23 from Ruben Harutyunyan harutyunyan.ruben@gmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #24 from Ruben Harutyunyan harutyunyan.ruben@gmail.com --- Created attachment 137789 --> https://bugs.freedesktop.org/attachment.cgi?id=137789&action=edit dmesg log (maximum verbosity) RX580
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #25 from Ruben Harutyunyan harutyunyan.ruben@gmail.com --- 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=...
Breaking commit: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.15-dc&id=...
Keep in mind that you need https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.15-dc&id=... 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.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #26 from Harry Wentland harry.wentland@amd.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #27 from Ruben Harutyunyan harutyunyan.ruben@gmail.com --- 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!
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #28 from Justin Mitzel katoflip@protonmail.com --- I'm not sure what the status of this bug is, but it's only gotten worse with kernel 4.16 and the amd-staging-drm-next branch.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Justin Mitzel katoflip@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|[dc] Screen flickering |Screen flickering under |under amdgpu-experimental |amdgpu-experimental [buggy |[buggy auto power profile] |auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #29 from Hadrien Lacour hadrien.lacour@posteo.net --- For what it's worth, the problem seems gone since I switched from 4.16.16 to 4.17.2 (with CONFIG_DRM_AMD_DC=y).
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #30 from L.Y. Sim onlylys@protonmail.com --- I have this issue on a 3840x1600 Acer XR382CQK with an RX560 with Kernel 4.18.5-1 on Manjaro.
When I set the refresh rate to 75Hz, severe artifacts and flickering appear.
Both
echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level and
echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level
stop the flickering and artifacting, and I can see via
cat /sys/class/drm/card0/device/pp_dpm_mclk
that the memory clocks are set to 1750Mhz and 300Mhz respectively.
However, if /sys/class/drm/card0/device/power_dpm_force_performance_level is set to auto, I can see (via watching /sys/class/drm/card0/device/pp_dpm_mclk with time intervals around 0.1s), that the memory clock oscillates rapidly between 300Mhz, 625Mhz and 1750Mhz.
So it seems to me that the rapid change in memory frequency is what's causing the flickering.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #31 from Timothy Pearson tpearson@raptorengineering.com --- (In reply to L.Y. Sim from comment #30)
I have this issue on a 3840x1600 Acer XR382CQK with an RX560 with Kernel 4.18.5-1 on Manjaro.
When I set the refresh rate to 75Hz, severe artifacts and flickering appear.
Both
echo high > /sys/class/drm/card0/device/power_dpm_force_performance_leveland
echo low > /sys/class/drm/card0/device/power_dpm_force_performance_levelstop the flickering and artifacting, and I can see via
cat /sys/class/drm/card0/device/pp_dpm_mclkthat the memory clocks are set to 1750Mhz and 300Mhz respectively.
However, if /sys/class/drm/card0/device/power_dpm_force_performance_level is set to auto, I can see (via watching /sys/class/drm/card0/device/pp_dpm_mclk with time intervals around 0.1s), that the memory clock oscillates rapidly between 300Mhz, 625Mhz and 1750Mhz.
So it seems to me that the rapid change in memory frequency is what's causing the flickering.
Confirmed here on a Polaris 10 GPU (WX7100) on DisplayPort with the latest kernel master from GIT (4.19+). The workaround sequence above stops the irritating flickering. dc=0 alone does /not/ stop the flickering, and dc=1 yields no displays detected due to some other bug.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #32 from Peter x26874@freenet.de --- (In reply to L.Y. Sim from comment #30)
I have this issue on a 3840x1600 Acer XR382CQK with an RX560 with Kernel 4.18.5-1 on Manjaro.
When I set the refresh rate to 75Hz, severe artifacts and flickering appear.
Both
echo high > /sys/class/drm/card0/device/power_dpm_force_performance_leveland
echo low > /sys/class/drm/card0/device/power_dpm_force_performance_levelstop the flickering and artifacting, and I can see via
cat /sys/class/drm/card0/device/pp_dpm_mclkthat the memory clocks are set to 1750Mhz and 300Mhz respectively.
However, if /sys/class/drm/card0/device/power_dpm_force_performance_level is set to auto, I can see (via watching /sys/class/drm/card0/device/pp_dpm_mclk with time intervals around 0.1s), that the memory clock oscillates rapidly between 300Mhz, 625Mhz and 1750Mhz.
So it seems to me that the rapid change in memory frequency is what's causing the flickering.
I think the "rapid change in memory frequency" really is the problem: When I echo manual > /sys/class/drm/card0/device/power_dpm_force_performance_level and then echo "0" > /sys/class/drm/card0/device/pp_dpm_mclk or echo "1" > /sys/class/drm/card0/device/pp_dpm_mclk or echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk there is no more flickering. (This limits the memory clock to 300Mhz, 1000 or 2000Mhz on my RX580 card. Using Arch Linux kernel 4.18.16 by the way.)
Whereas or echo "0 1 2" > /sys/class/drm/card0/device/pp_dpm_mclk or any combination of 2 memory clock frequencies brings flickering back.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #33 from Alex Deucher alexdeucher@gmail.com --- The mclk switching needs to happen during the vblank period to avoid the flickering. If there is not enough time in the vblank period, you may see flickering outside of the blanking period. Can you figure out what modes and refresh rates exhibit this issue?
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #34 from bmilreu@gmail.com --- Alex this bug looks like the same I reported here https://bugs.freedesktop.org/show_bug.cgi?id=108322
The flickering issues I have with 75hz are gone after forcing profile to high.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #35 from Alex Deucher alexdeucher@gmail.com --- (In reply to bmilreu from comment #34)
The flickering issues I have with 75hz are gone after forcing profile to high.
The disables mclk switching by forcing the clocks to high. What modes and refresh rates exhibit the problem?
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tempel.julian@gmail.com
--- Comment #36 from Alex Deucher alexdeucher@gmail.com --- *** Bug 105300 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #37 from bmilreu@gmail.com --- (In reply to Alex Deucher from comment #35)
(In reply to bmilreu from comment #34)
The flickering issues I have with 75hz are gone after forcing profile to high.
The disables mclk switching by forcing the clocks to high. What modes and refresh rates exhibit the problem?
Any resolution at 75hz. My FullHD modelines are:
[ 802.898] (II) AMDGPU(0): Modeline "1920x1080"x0.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP) [ 802.898] (II) AMDGPU(0): Modeline "1920x1080"x0.0 170.00 1920 1928 1960 2026 1080 1105 1113 1119 +hsync +vsync (83.9 kHz e)
First one is 1080p@60hz (good), second is 1080p@75hz (flickers)
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #38 from bmilreu@gmail.com --- (In reply to Alex Deucher from comment #36)
*** Bug 105300 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=108322 - Also related.
When I tested 4.18 kernel the bug used to trigger only @>73hz after sleep/wakeup. In latest drm-next-4.21-wip triggers as soon as I switch to 75hz. If I switch back from 75hz to 60hz it keeps flickering until I manually turn my monitor off/on.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #39 from bmilreu@gmail.com --- Another interesting info, even with amdgpu.dc=0 I get flickering @75hz. Difference is the flickering immediatly stops when I switch back to 60hz (no need to reboot or switch monitor off/on)
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #40 from tempel.julian@gmail.com --- Still having this issue with 2560 x 1440 @ 75Hz and latest 4.21-wip kernel. Manually forcing a single VRAM clock state eliminates the flicker artifacts. As soon as there is dynamic VRAM clocking happening, it flickers.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #41 from afm af_mcinerney@hotmail.com --- RX 570 1002:67df [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef) Kernel: 4.19.2-300.fc29.x86_64 1920x1080 59.93*+
Lots of strange flickering and black lines with dc=1. Strange ghosting and screen corruption with dc=0
echo manual > /sys/class/drm/card0/device/power_dpm_force_performance_level echo "0" > /sys/class/drm/card0/device/pp_dpm_mclk
Fixes the issue.
echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk echo "0" > /sys/class/drm/card0/device/pp_dpm_mclk echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk
Produces screen corruption for half a second on each change. Across all 3 monitors.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #42 from afm af_mcinerney@hotmail.com --- Just to add. I noticed the corruption during the plymouth boot screen too. After just waking the monitors from DPMS i got corruption until I echo'd 0 again.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #43 from afm af_mcinerney@hotmail.com --- OK really sorry for the noise on this ticket. It seems I did this to myself with featuremask 0xfffffff . All is working without it. (i had been using watman gtk)
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #44 from tempel.julian@gmail.com --- I have this issue also without amdgpu.ppfeaturemask=0xffffffff. amdgpu.dc 0 or 1 doesn't make a difference for me.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #45 from bmilreu@gmail.com --- A temporary way to at least lock mclck forever would be great until this is fixed. There is no sane way to do it permanently (some events switch it back to auto, IE resolution changes and sleep/wake)
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #46 from tempel.julian@gmail.com --- As a workaround, a timer job/script writing every few seconds might do the trick.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #47 from tempel.julian@gmail.com --- I had the chance to test three different GPUs: RX 560: flickers RX 580: flickers RX Vega 56: doesn't flicker (and saves way more power than Polaris at the same time)
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #48 from Tim Writer Tim.Writer@amd.com --- I'm out-of-office for jury duty Nov. 19 - Dec. 11, returning on Dec. 12. I will be checking e-mail daily and will endeavour to route important e-mail to my team.
Regards, Tim
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #49 from bmilreu@gmail.com --- (In reply to tempel.julian from comment #46)
As a workaround, a timer job/script writing every few seconds might do the trick.
I tried a systemd timer but it floods my dmesg every time it triggers and also caused weird lag in systemd monitoring, perhaps writing to sysfs constantly has a noticeable cost. Maybe someone could hack a kernel option to force it to high as a temporary workaround? Unfortunately I'm ignorant in C.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #50 from tempel.julian@gmail.com --- Or just watch pp_dpm_mclk e.g. every second instead of constantly writing into it, and write only in case of a change?
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #51 from Alex Deucher alexdeucher@gmail.com --- Does this patch help? https://patchwork.freedesktop.org/patch/264781/ or this patch for older kernels: https://bugs.freedesktop.org/attachment.cgi?id=142660
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #52 from tempel.julian@gmail.com --- It still flickers with 4.21-wip build including this patch.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #53 from Alex Deucher alexdeucher@gmail.com --- Created attachment 142662 --> https://bugs.freedesktop.org/attachment.cgi?id=142662&action=edit possible fix
How about this patch?
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |almoped@gmail.com
--- Comment #54 from Alex Deucher alexdeucher@gmail.com --- *** Bug 96868 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #55 from bmilreu@gmail.com --- (In reply to Alex Deucher from comment #53)
Created attachment 142662 [details] [review] possible fix
How about this patch?
for me it still flickers after sleep/wake @75hz unless I lock mclck
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #56 from tempel.julian@gmail.com --- (In reply to bmilreu from comment #55)
(In reply to Alex Deucher from comment #53)
Created attachment 142662 [details] [review] [review] possible fix
How about this patch?
for me it still flickers after sleep/wake @75hz unless I lock mclck
I can confirm this. For me, it instantly starts flickering after starting x.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #57 from tempel.julian@gmail.com --- Instead of my usual DL-DVI display, I connected a Samsung C27H711 via Display Port. It officially offers 2560x1440 75Hz and the very same flickering issue occurs.
I suspect the Polaris Windows driver has the same or a similar issue, as there is sometimes black flashing when there is heavy VRAM clock jumping going on, e.g. in games during loading screens or when watching videos with low GPU load in mpv.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #58 from tempel.julian@gmail.com --- I've written a small script to only write into pp_dpm_mclk when it's not forced into pstate 2:
#!/bin/bash
if ! cat /sys/class/drm/card0/device/pp_dpm_mclk | grep -xqFe "2: 2250Mhz *" then echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk fi
---
Can be restarted every 1s via systemd:
[Unit] Description=watch-pp_dpm_mclk StartLimitIntervalSec=0
[Service] ExecStart=.../watch-pp_dpm_mclk.sh Restart=always RestartSec=1
[Install] WantedBy=multi-user.target
---
Seems to do the trick without nasty side effects.
Real fixes for the memory clock change flicker and the not sticking pp_dpm_mclk value would of course be better.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #59 from bmilreu@gmail.com --- 4.20 released with this still, no fix in the way?
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #60 from Scias shining.scias@gmail.com --- Still happening on Linux-amd-staging 4.21 unfortunately. Even with VariableRefresh/Freesync working.
I also noticed it doesn't happen if using dual/multiple screens. Looks like the vram clock is forced to the highest state in this case. Is this a normal behavior?
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #61 from Tim Writer Tim.Writer@amd.com --- I'm out-of-office, returning on Jan. 3. I will be checking e-mail but responses will be delayed.
Regards, Tim
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #62 from Alex Deucher alexdeucher@gmail.com --- (In reply to Scias from comment #60)
I also noticed it doesn't happen if using dual/multiple screens. Looks like the vram clock is forced to the highest state in this case. Is this a normal behavior?
Yes. Memory reclocking has to happen during the vblank period to avoid flickering. If the vblank period is too short or you have multiple monitors where the vblank periods are not aligned memory cannot be dynamically reclocked.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|michel@daenzer.net |
--- Comment #63 from Michel Dänzer michel@daenzer.net --- Removing myself from the CC list, I get updates via mailing lists.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #64 from marlock9@gmail.com --- Just received 4.20 kernel in ArchLinux and got the same problem. High performance profile or manual with max memory clock works around.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #65 from bmilreu@gmail.com --- Please look at this devs, still no solution in mind?
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #66 from Lefteris Chatzimparmpas lefcha@fastmail.com --- While the workaround with power_dpm_force_performance_level/pp_dpm_mclk works for me, I found another way to stop the flickering, which I mention here in case it helps debugging.
My monitor has a native resolution of 1920x1200 at 75Hz or 60Hz through DP, and 60Hz through HDMI. It supports Freesync through DP, but I have that disabled. I'm using the 4.19 kernel.
When through a DP cable, if I switch the resolution to 1920x1080 at 60Hz, and then revert back to the native 1920x1200 at 75Hz, the flickering stops for good. If I turn off and on the monitor, everything is still good, but if I reboot or do a sleep and wakeup of the computer, then the flickering returns, that is until I switch the resolution again.
Through HDMI, I don't get the flickering on the native resolution, possibly because I get this max resolution at 60Hz. But note that through DP, changing to 60Hz alone doesn't seem to help.
Also, through HDMI, I can make the flickering start, if I switch to 1440x900 at 75Hz, and then it only stops if I switch to 1920x1080 at 60Hz and then back to native.
Finally, after I got the flickering stop with the resolution switch, I tried watching the pp_dpm_mclk, and I could see it changing values very fast, similar to when I had the flickering problem.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #67 from Maxim Ivanov m.ivanov2k@gmail.com --- Any updates on this? It seems like this bug has been around for quite a while now.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Maxim Ivanov m.ivanov2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|medium |high
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #68 from bmilreu@gmail.com --- At this point we need at least a workaround. Add a runtime kernel parameter that keeps memory clock maxed up always, even after sleep/wake and resolution changes.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #69 from Bastian brotwurst85@googlemail.com --- Distro/Kernel: Ubuntu 18.04.2/5.0.2 GPU AMD: Readon RX570 - Mesa 19.0 Display: Iiyama G23530HSU 75hz Desktop: Gnome
video: https://www.youtube.com/watch?v=gNJ2kJ8hsHA
Have the same problem as the op. The problems started with the 4.20 Kernels. Had not this problem with 4.19 LTS Kernels. The flickering doesn't appear on wayland if I choose only 60hz. On xorg it is irrelevant how much hz I use, it flickers regardless.
sudo -i echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk
Fixes the flickering.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
George Scorer georgescorer@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|high |low Severity|major |minor
--- Comment #70 from George Scorer georgescorer@yahoo.co.uk --- Building on julien tempel's workaround, here's a somewhat more complex script to manage the memory p-state jumps. It switches between low and high memory p-states very reluctantly, so minimizing instances of flickering. I'm not a bash expert so please excuse the clumsy coding, but this works for me.
#!/bin/bash
# Each memory p-state switch causes a screen flicker. Tweak these variables to match # your personal 'flicker aversion' vs efficiency trade-off. CORE_P_STATE_UP=6 # The gpu core p-state at which we should jump up to memory p-state 2 CORE_P_STATE_DOWN=1 # The gpu core p-state at which we should drop down to low memory p-state UP_DELAY=2 # in seconds. How long to stay in low memory p-state before checking whether we can jump up to 2. DOWN_DELAY=10 # in seconds. How long to stay in memory p-state 2 before checking whether we can drop down to low. SLEEP_INTERVAL=1 # in seconds. How frequently we should poll the core p-state. LOW_MEM_STATE=0 # Choose between 0 & 1
# Sysfs paths here are hardcoded for one amdgpu card at card0; adjust as needed. FILE_PERF_LEVEL=/sys/class/drm/card0/device/power_dpm_force_performance_level FILE_MEM_P_STATE=/sys/class/drm/card0/device/pp_dpm_mclk FILE_CORE_P_STATE=/sys/class/drm/card0/device/pp_dpm_sclk
# check for root privileges if [ $UID -ne 0 ] then echo "Writing to sysfs requires root privileges; relaunch as root" exit 1 fi
# Set gpu performance level control to manual # echo "Setting performance level control to manual" echo "manual" > "$FILE_PERF_LEVEL"
# Read the current core p-state and set a corresponding initial memory p-state
CORE_P_STATE="$(grep -F '*' $FILE_CORE_P_STATE)" CORE_P_STATE=${CORE_P_STATE:0:1}
if [ "$CORE_P_STATE" -ge "$CORE_P_STATE_UP" ]; then MEM_P_STATE=2 else MEM_P_STATE=$LOW_MEM_STATE fi
echo "$MEM_P_STATE" > "$FILE_MEM_P_STATE" PROPOSED_MEM_P_STATE=$MEM_P_STATE
function check_core_p_state {
CORE_P_STATE="$(grep -F '*' $FILE_CORE_P_STATE)" CORE_P_STATE=${CORE_P_STATE:0:1}
# Propose what the corresponding memory p-state should be OLD_PROPOSED_MEM_P_STATE=$PROPOSED_MEM_P_STATE PROPOSED_MEM_P_STATE=$MEM_P_STATE if [ "$CORE_P_STATE" -ge "$CORE_P_STATE_UP" ]; then PROPOSED_MEM_P_STATE=2 elif [ "$CORE_P_STATE" -le "$CORE_P_STATE_DOWN" ]; then PROPOSED_MEM_P_STATE=$LOW_MEM_STATE fi
if [ "$PROPOSED_MEM_P_STATE" -ne "$MEM_P_STATE" ]; then # We want to change so determine where we are in the countdown. if [ "$PROPOSED_MEM_P_STATE" -ne "$OLD_PROPOSED_MEM_P_STATE" ]; then if [ "$PROPOSED_MEM_P_STATE" -eq 2 ]; then CHANGE_COUNTDOWN=$UP_DELAY else CHANGE_COUNTDOWN=$DOWN_DELAY fi fi (( CHANGE_COUNTDOWN = $CHANGE_COUNTDOWN - $SLEEP_INTERVAL ))
if [ $CHANGE_COUNTDOWN -le 0 ]; then # The countdown has reached 0 so change the memory p-state. MEM_P_STATE=$PROPOSED_MEM_P_STATE echo "$MEM_P_STATE" > "$FILE_MEM_P_STATE" fi # else # we don't want to change. fi
# echo "Old Prop Mem Core Countdown" # echo " $OLD_PROPOSED_MEM_P_STATE $PROPOSED_MEM_P_STATE $MEM_P_STATE $CORE_P_STATE $CHANGE_COUNTDOWN" # echo "" }
function reset_on_fail { echo "Exiting, setting memory p-state to 2" echo "manual" > "$FILE_PERF_LEVEL" echo "2" > "$FILE_MEM_P_STATE" exit 1 }
# always try to fix memory p-state 2 on failure trap "reset_on_fail" SIGINT SIGTERM
function run_daemon { while :; do sleep $SLEEP_INTERVAL check_core_p_state done }
# start the loop
run_daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102646
George Scorer georgescorer@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|low |high Severity|minor |major
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #71 from bmilreu@gmail.com --- (In reply to George Scorer from comment #70)
Building on julien tempel's workaround, here's a somewhat more complex script to manage the memory p-state jumps. It switches between low and high memory p-states very reluctantly, so minimizing instances of flickering. I'm not a bash expert so please excuse the clumsy coding, but this works for me.
#!/bin/bash
# Each memory p-state switch causes a screen flicker. Tweak these variables to match # your personal 'flicker aversion' vs efficiency trade-off. CORE_P_STATE_UP=6 # The gpu core p-state at which we should jump up to memory p-state 2 CORE_P_STATE_DOWN=1 # The gpu core p-state at which we should drop down to low memory p-state UP_DELAY=2 # in seconds. How long to stay in low memory p-state before checking whether we can jump up to 2. DOWN_DELAY=10 # in seconds. How long to stay in memory p-state 2 before checking whether we can drop down to low. SLEEP_INTERVAL=1 # in seconds. How frequently we should poll the core p-state. LOW_MEM_STATE=0 # Choose between 0 & 1
# Sysfs paths here are hardcoded for one amdgpu card at card0; adjust as needed. FILE_PERF_LEVEL=/sys/class/drm/card0/device/power_dpm_force_performance_level FILE_MEM_P_STATE=/sys/class/drm/card0/device/pp_dpm_mclk FILE_CORE_P_STATE=/sys/class/drm/card0/device/pp_dpm_sclk
# check for root privileges if [ $UID -ne 0 ] then echo "Writing to sysfs requires root privileges; relaunch as root" exit 1 fi
# Set gpu performance level control to manual # echo "Setting performance level control to manual" echo "manual" > "$FILE_PERF_LEVEL"
# Read the current core p-state and set a corresponding initial memory p-state
CORE_P_STATE="$(grep -F '*' $FILE_CORE_P_STATE)" CORE_P_STATE=${CORE_P_STATE:0:1}
if [ "$CORE_P_STATE" -ge "$CORE_P_STATE_UP" ]; then MEM_P_STATE=2 else MEM_P_STATE=$LOW_MEM_STATE fi
echo "$MEM_P_STATE" > "$FILE_MEM_P_STATE" PROPOSED_MEM_P_STATE=$MEM_P_STATE
function check_core_p_state {
CORE_P_STATE="$(grep -F '*' $FILE_CORE_P_STATE)" CORE_P_STATE=${CORE_P_STATE:0:1}
# Propose what the corresponding memory p-state should be OLD_PROPOSED_MEM_P_STATE=$PROPOSED_MEM_P_STATE PROPOSED_MEM_P_STATE=$MEM_P_STATE if [ "$CORE_P_STATE" -ge "$CORE_P_STATE_UP" ]; then PROPOSED_MEM_P_STATE=2 elif [ "$CORE_P_STATE" -le "$CORE_P_STATE_DOWN" ]; then PROPOSED_MEM_P_STATE=$LOW_MEM_STATE fi
if [ "$PROPOSED_MEM_P_STATE" -ne "$MEM_P_STATE" ]; then # We want to change so determine where we are in the countdown. if [ "$PROPOSED_MEM_P_STATE" -ne "$OLD_PROPOSED_MEM_P_STATE" ]; then if [ "$PROPOSED_MEM_P_STATE" -eq 2 ]; then CHANGE_COUNTDOWN=$UP_DELAY else CHANGE_COUNTDOWN=$DOWN_DELAY fi fi (( CHANGE_COUNTDOWN = $CHANGE_COUNTDOWN - $SLEEP_INTERVAL ))
if [ $CHANGE_COUNTDOWN -le 0 ]; then# The countdown has reached 0 so change the memory p-state. MEM_P_STATE=$PROPOSED_MEM_P_STATE echo "$MEM_P_STATE" > "$FILE_MEM_P_STATE" fi # else # we don't want to change. fi
# echo "Old Prop Mem Core Countdown" # echo " $OLD_PROPOSED_MEM_P_STATE $PROPOSED_MEM_P_STATE $MEM_P_STATE $CORE_P_STATE $CHANGE_COUNTDOWN" # echo "" }
function reset_on_fail { echo "Exiting, setting memory p-state to 2" echo "manual" > "$FILE_PERF_LEVEL" echo "2" > "$FILE_MEM_P_STATE" exit 1 }
# always try to fix memory p-state 2 on failure trap "reset_on_fail" SIGINT SIGTERM
function run_daemon { while :; do sleep $SLEEP_INTERVAL check_core_p_state done }
# start the loop
run_daemon
Thanks for the script, it doesn't work 100% of the time but the flickers are very rare. Good thing about it is that you still save power when idle since it reclocks back. I'd guess similar logic could be used to fix the driver while still having the feature working, just reclocking less agressively.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #72 from tempel.julian@gmail.com --- Well, I just accepted to lose 2Hz and use a custom edid with 73Hz instead of 75.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #73 from Bastian brotwurst85@googlemail.com --- (In reply to Bastian from comment #69)
Distro/Kernel: Ubuntu 18.04.2/5.0.2 GPU AMD: Readon RX570 - Mesa 19.0 Display: Iiyama G23530HSU 75hz Desktop: Gnome
video: https://www.youtube.com/watch?v=gNJ2kJ8hsHA
Have the same problem as the op. The problems started with the 4.20 Kernels. Had not this problem with 4.19 LTS Kernels. The flickering doesn't appear on wayland if I choose only 60hz. On xorg it is irrelevant how much hz I use, it flickers regardless.
sudo -i echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk
Fixes the flickering.
Just a quick update. After switching from HDMI to DisplayPort the issue resolved itself for me.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #74 from bmilreu@gmail.com --- (In reply to Bastian from comment #73)
(In reply to Bastian from comment #69)
Distro/Kernel: Ubuntu 18.04.2/5.0.2 GPU AMD: Readon RX570 - Mesa 19.0 Display: Iiyama G23530HSU 75hz Desktop: Gnome
video: https://www.youtube.com/watch?v=gNJ2kJ8hsHA
Have the same problem as the op. The problems started with the 4.20 Kernels. Had not this problem with 4.19 LTS Kernels. The flickering doesn't appear on wayland if I choose only 60hz. On xorg it is irrelevant how much hz I use, it flickers regardless.
sudo -i echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk
Fixes the flickering.
Just a quick update. After switching from HDMI to DisplayPort the issue resolved itself for me.
That's interesting. It's the opposite for me - only DP flickers, not HDMI. Lots of people on reddit have been discovering this as they're coming from older kernels, only this week I've helped 4 different posters asking about it. We'd like to hear anything from devs at this point so I'll CC this to AMD's DC dev Nicholas Kazlauskas.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #75 from Antonio rafilopez95@outlook.com --- Something I've noticed is that on my system, playing games doesn't flicker (Bordelands 2 for example) when there's a lot of action/movement.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #76 from IvvanVG ivvangrigo@gmail.com --- problem because of this commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=l... discussion on Ubuntu was here https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/181... Also affects RX580. I think that the bug applies to 400, 500 series of graphics cards
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #77 from Garrett dragonhart6505@gmail.com --- small change to a comment above:
sudo -i echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level echo "2" > /sys/class/drm/card0/device/pp_dpm_sclk (notice NOT pp_dpm_mclk)
allows my 75hz display to work without flicker at 75hz with RX580. it was driving me INSANE that i couldnt use my monitors native refresh. have to do this every reboot, which is annoying, but it works.
Note: using Solus Budgie with kernel 5.0.5-113...ymmv
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #78 from Garrett dragonhart6505@gmail.com --- (In reply to IvvanVG from comment #76)
problem because of this commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/ ?h=linux-4.18.y&id=d9ef158adf04b81772a7e9d682a054614ebac2fd discussion on Ubuntu was here https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/ 1813701 Also affects RX580. I think that the bug applies to 400, 500 series of graphics cards
affected my RX580 until i ran the command i commented above. on my RX580, locking the sclk fixed flickering on 75hz refresh. yea its running a little harder just to keep the display from flickering on the desktop but it stays cool enough im not worried about it
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #79 from Garrett dragonhart6505@gmail.com --- turns out if you just echo "0" for both sclk and mclk it fixes it at 75hz. cant say for higher refresh rate, but my GPU is running stock now. what a weird problem to have :/
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #80 from Garrett dragonhart6505@gmail.com --- well...even better solution: install Radeon-Profile
sudo su cd /usr/bin radeon-profile
boom...manual control with the radeon-profile GUI...something i've not once seen mentioned in any tutorials. as long as you know what you're card is capable of, you can manually set clock percentages and a custom fan curve.
fan curve only stays active as long as radeon-profile is opened as far as i can tell
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #81 from tempel.julian@gmail.com --- I really hope this bug is not just not occurring with Vega because it uses HBM2, so that we won't see it again with Navi GPUs which probably will use GDDR5/6.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #82 from kyrottimus@yahoo.com --- My solution, well more of a workaround and since I had this problem even with default MESA that comes packaged with Kernel 5.05.XX, was to retune my monitor to my GPU instead of letting my GPU try to do it automatically the other way around or waiting on updated kernel/drivers/firmware/microcode to address this problem for me.
TL:DR--using xrandr to tell my monitor to stay in step with my GPU.
This fixed it for me, your mileage may vary:
Below is an example of commands in the terminal to activate a new monitor refresh rate in the "display" settings in Manjaro Linux to tune your monitor to a precise frequency: in the case of a Radeon (Polaris) RX580 or RX590 and a 75Hz (max) ASUS VG245H HDMI gaming monitor, my target was 73Hz (~-2Hz from peak) to run with the GPU properly without any horizontal black/green line flickering.
I chose 73Hz because I already tried tuning to my monitor's closest accurate refresh rate (74.89Hz) manually off the reported 75Hz and it still flickered, and the next closest setting for my Monitor was ~73Hz.
Keep in mind, with the below example, your variables need to be pulled from both the cvt command at the top (with your desired resolution/refresh rate plugged in after the cvt command) and then plug that "Modeline" part (after the word Modeline) into the xrandr --newmode command.
YOUR COMMANDS WILL PROBABLY NEED DIFFERENT VARIABLES.
Then, using xrandr -q find your display type and ID (for me it was HDMI-A-0) and plug that into your final command along with your desired resolution/refresh info: example here of
$ xrandr --verbose --addmode HDMI-A-0 "1920x1080_73.00"
*******BEGIN TERMINAL EXAMPLE********
[username@thisalinuxpc ~]$ cvt 1920 1080 73 # 1920x1080 72.87 Hz (CVT) hsync: 82.27 kHz; pclk: 213.25 MHz Modeline "1920x1080_73.00" 213.25 1920 2056 2256 2592 1080 1083 1088 1129 -hsync +vsync [username@thisalinuxpc ~]$ xrandr --newmode "1920x1080_73.00" 213.25 1920 2056 2256 2592 1080 1083 1088 1129 -hsync +vsync [username@thisalinuxpc ~]$ xrandr -q Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384 DisplayPort-0 disconnected (normal left inverted right x axis y axis) DisplayPort-1 disconnected (normal left inverted right x axis y axis) HDMI-A-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 299mm 1920x1080 60.00*+ 74.99 50.00 59.94 1600x1200 60.00 1680x1050 59.88 1280x1024 75.02 60.02 1440x900 59.90 1280x960 60.00 1366x768 59.79 1280x800 60.00 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.03 70.07 60.00 832x624 74.55 800x600 72.19 75.00 60.32 56.25 720x576 50.00 720x480 60.00 59.94 640x480 75.00 72.81 66.67 60.00 59.94 720x400 70.08 HDMI-A-1 disconnected (normal left inverted right x axis y axis) DVI-D-0 disconnected (normal left inverted right x axis y axis) 1920x1080_73.00 (0x6f2) 213.250MHz -HSync +VSync h: width 1920 start 2056 end 2256 total 2592 skew 0 clock 82.27KHz v: height 1080 start 1083 end 1088 total 1129 clock 72.87Hz [username@thisalinuxpc ~]$ xrandr --verbose --addmode HDMI-A-0 1920x1080_73.00 [username@thisalinuxpc ~]$ xrandr --output HDMI-A-0 --mode 1920x1080_73.00
*******END TERMINAL EXAMPLE*********
Doing the above commands, 72.9Hz then showed up in the "display" options (in panel menu) and selecting it works great with zero flicker.
Now to make it stick after reboot/relog (if it works to your liking):
Make a script file called "custom_refresh" (without quotes, no .sh)...put the following in it (change yours to fit your proper command outputs from above, accordingly):
#!/bin/sh xrandr --newmode "1920x1080_73.00" 213.25 1920 2056 2256 2592 1080 1083 1088 1129 -hsync +vsync xrandr --verbose --addmode HDMI-A-0 1920x1080_73.00 xrandr --output HDMI-A-0 --mode 1920x1080_73.00
#[end of commands-don't include this line]
Save this file to your /home/CHANGEMETOYOURUSERNAME/ dir (change CHANGEMETOYOURUSERNAME to your user name), quit, then make a new file called "trigger_custom_refresh.sh" (no quotes) and put this in it:
#!/bin/sh cd /usr/bin/ xfce4-terminal -e 'bash -c "/home/CHANGEMETOYOURUSERNAME/custom_refresh"'
#[end of commands-don't include this line]
(or use whatever your favorite terminal emulator is instead, does not have to be xfce4-terminal; don't forget to change the CHANGEMETOYOURUSERNAME to whatever your user name is, or whatever directory where you saved your custom_refresh script is properly reflected in the command)
Save, quit. Cd to where this file is (I just stick both these files in my /home/ dir and run this command straight from a raw terminal) and in terminal make it executable:
$ chmod +x ./trigger_custom_refresh.sh
To test it, reboot first (to clear the initial xrandr settings out and go back to default), then use this command:
$ ./trigger_custom_refresh.sh
Your monitor should flicker as it restarts under the new refresh rate. If it worked (you can check either by looking at the monitor display settings or look at xfce4-display-settings or equivalent), you now have a functional script to activate your custom refresh rate.
Now to make this auto load with each reboot or relog: add the trigger_custom_refresh.sh file to startup applications if necessary so it auto-loads and triggers immediately after session-login. No sudo required, it'll load per user session or higher depending on what folder you run it out of.
****************************
LAST NOTE: I've found enabling "Tear Free" on my card, an RX590 to be necessary to remove tearing in Proton+Vulkan games and some other OpenGL games.
TO ENABLE AMD's TEARFREE FEATURE:
How to enable AMD's "Tear Free" option on their AMD Radeon RX 5xx (Polaris) cards:
Time to mess around with xorg.conf. https://wiki.archlinux.org/index.php/AMDGPU#Xorg_configuration 25
Open a terminal and type the command:
sudo mousepad /etc/X11/xorg.conf.d/20-amdgpu.conf
(or substitute mousepad for whatever basic text editor you like)
Then copy and paste the below text starting with "Section" and ending with "EndSection" into the text editor.
Section "Device" Identifier "AMD" Driver "amdgpu" Option "TearFree" "true" EndSection
Save and quit. This is all presumed that you're using the open source MESA driver. After that. Reboot your computer.
Enjoy TearFree
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #83 from Tom B tom@r.je --- I have a similar problem with my Radeon VII. My testing/experiments are outlined here: https://bugs.freedesktop.org/show_bug.cgi?id=110510 sorry for the long post!
However my bug seems slightly different albeit related.
1. The flicker only occurs on my HDMI monitor. It's a flicker and sometimes the screen will go black for a couple of seconds
2. If the HDMI monitor is the only monitor connected I can set the refresh rate to 59.94 instead of 60.00 and it is fine
3. If the HDMI monitor and a displayport monitor are both connected the flicker still occurs. However, trying to set the HDMI monitor to 59.94hz causes the system to freeze and I have to do a hard reset (it's fine if the HDMI monitor is the only monitor)
4. Setting power_dpm_force_performance_level to high alone does not fix it. But by running the higher power state I can set the HDMI monitor to 59.94hz without the system freezing
In short: I need to use 59.94hz to stop the flickering and I need to use high power state to set the refresh rate without freezing the entire system.
Although this is an acceptable workaround I would like to see a proper fix.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #84 from evan.quan@amd.com evan.quan@outlook.com --- Created attachment 144237 --> https://bugs.freedesktop.org/attachment.cgi?id=144237&action=edit Clean up the fast uclk switch settings on SMU7 asics
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #85 from evan.quan@amd.com evan.quan@outlook.com --- Created attachment 144238 --> https://bugs.freedesktop.org/attachment.cgi?id=144238&action=edit Added some verbose debugs
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #86 from evan.quan@amd.com evan.quan@outlook.com --- Can anyone give the attachment 144237 a try and let me know the result? And if the issue still exists, please apply attachment 144238 also which can provide more debug outputs.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #87 from tempel.julian@gmail.com --- Applying the patch to 5.0, 5.1 and drm-next-5.2-wip fails with
patching file drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c Hunk #5 FAILED at 3943. Hunk #6 succeeded at 3951 (offset -7 lines). Hunk #7 succeeded at 4035 (offset -7 lines). Hunk #8 succeeded at 4152 (offset -7 lines). Hunk #9 succeeded at 4669 (offset -7 lines). 1 out of 9 hunks FAILED -- saving rejects to file drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c.rej patching file drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.h
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #88 from bmilreu@gmail.com --- (In reply to tempel.julian from comment #87)
Applying the patch to 5.0, 5.1 and drm-next-5.2-wip fails with
patching file drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c Hunk #5 FAILED at 3943. Hunk #6 succeeded at 3951 (offset -7 lines). Hunk #7 succeeded at 4035 (offset -7 lines). Hunk #8 succeeded at 4152 (offset -7 lines). Hunk #9 succeeded at 4669 (offset -7 lines). 1 out of 9 hunks FAILED -- saving rejects to file drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c.rej patching file drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.h
same here, can't figure which kernel is this based at
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #89 from Alex Deucher alexdeucher@gmail.com --- Try against this branch: https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #90 from tempel.julian@gmail.com --- Same issue:
patching file drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c Hunk #5 FAILED at 3943. Hunk #6 succeeded at 3954 (offset -4 lines). Hunk #7 succeeded at 4038 (offset -4 lines). Hunk #8 succeeded at 4155 (offset -4 lines). Hunk #9 succeeded at 4672 (offset -4 lines). 1 out of 9 hunks FAILED -- saving rejects to file drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c.rej patching file drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.h
https://bugs.freedesktop.org/show_bug.cgi?id=102646
magist3r magist3r@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #144237|0 |1 is obsolete| |
--- Comment #91 from magist3r magist3r@gmail.com --- Created attachment 144253 --> https://bugs.freedesktop.org/attachment.cgi?id=144253&action=edit fixed patch
I fixed the patch and can apply it on top of amd-drm-next and vanilla kernel 5.0.11 (my current kernel). Unfortunately it doesn't help. I added 'verbose debug' patch too, here is my output.
1) Before applying high memory profile workaround: kernel: amdgpu: [powerplay] min_core_set_clock: 30000 kernel: amdgpu: [powerplay] min_mem_set_clock: 30000 kernel: amdgpu: [powerplay] vrefresh: 75 kernel: amdgpu: [powerplay] min_vblank_time: 464 kernel: amdgpu: [powerplay] num_display: 2 kernel: amdgpu: [powerplay] multi_monitor_in_sync: 0 kernel: amdgpu: [powerplay] performance level 0 memory clock = 30000 kernel: amdgpu: [powerplay] performance level 0 engine clock = 30000 kernel: amdgpu: [powerplay] performance level 1 memory clock = 200000 kernel: amdgpu: [powerplay] performance level 1 engine clock = 136600 kernel: amdgpu: [powerplay] mclk_latency_table entry0 frequency = 30000 kernel: amdgpu: [powerplay] mclk_latency_table entry0 latency = 330 kernel: amdgpu: [powerplay] mclk_latency_table entry1 frequency = 100000 kernel: amdgpu: [powerplay] mclk_latency_table entry1 latency = 330 kernel: amdgpu: [powerplay] mclk_latency_table entry2 frequency = 200000 kernel: amdgpu: [powerplay] mclk_latency_table entry2 latency = 330
2) After: kernel: amdgpu: [powerplay] min_core_set_clock: 30000 kernel: amdgpu: [powerplay] min_mem_set_clock: 30000 kernel: amdgpu: [powerplay] vrefresh: 75 kernel: amdgpu: [powerplay] min_vblank_time: 464 kernel: amdgpu: [powerplay] num_display: 2 kernel: amdgpu: [powerplay] multi_monitor_in_sync: 0 kernel: amdgpu: [powerplay] performance level 0 memory clock = 200000 kernel: amdgpu: [powerplay] performance level 0 engine clock = 30000 kernel: amdgpu: [powerplay] performance level 1 memory clock = 200000 kernel: amdgpu: [powerplay] performance level 1 engine clock = 136600 kernel: amdgpu: [powerplay] mclk_latency_table entry0 frequency = 30000 kernel: amdgpu: [powerplay] mclk_latency_table entry0 latency = 330 kernel: amdgpu: [powerplay] mclk_latency_table entry1 frequency = 100000 kernel: amdgpu: [powerplay] mclk_latency_table entry1 latency = 330 kernel: amdgpu: [powerplay] mclk_latency_table entry2 frequency = 200000 kernel: amdgpu: [powerplay] mclk_latency_table entry2 latency = 330
My GPU is RX580 8Gb with 2 monitors connected through HDMI.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #92 from magist3r magist3r@gmail.com --- Just for the reference: screen flickering appears for me only with amdgpu.ppfeaturemask=0xffffffff. I think to flash my card with OC'ed BIOS and disable buggy OverDrive completely.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Seth Lorecanth issethlorecanth@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |issethlorecanth@gmail.com
--- Comment #93 from Seth Lorecanth issethlorecanth@gmail.com --- GPU/Stack RX 560/amdgpu/linux console CPU: R7 2700X Distro/Kernel: LFS/5.1.5
I have been experiencing what appears to be the same issue on any kernel newer than 4.14 that I’ve tried. I had been running Manjaro 4.14 which works fine, but I briefly tried LFS and discovered this issue. I’ve tried some different kernels, but all the ones after 4.14 exhibit the same issue.
The video shows a single flicker, but the flickers occur fairly regularly when scrolling.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #94 from magist3r magist3r@gmail.com --- Created attachment 144565 --> https://bugs.freedesktop.org/attachment.cgi?id=144565&action=edit proposed fix
FINALLY!!! I fixed the issue. A small patch with a fix is in the attachment. Feel free to suggest a better solution, but it works for me without any issues.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #95 from tempel.julian@gmail.com --- This is probably what some people want, but it forces VRAM into highest state with amdgpu.dc=1, while it has no effect with amdgpu.dc=0 (still flickers).
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #96 from magist3r magist3r@gmail.com --- (In reply to tempel.julian from comment #95)
but it forces VRAM into highest state with amdgpu.dc=1
Yes, and this is what the kernel code does to prevent flickering. My patch is only about doing the same thing with PP_OVERDRIVE_MASK enabled.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Ahzo@tutanota.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Ahzo@tutanota.com
--- Comment #97 from Ahzo@tutanota.com --- Created attachment 144950 --> https://bugs.freedesktop.org/attachment.cgi?id=144950&action=edit Patch to fix the problem
TLDR: A script to reproduce and a patch to fix this problem are attached.
The problem occurs when switching between high and low GPU memory frequencies at specific time intervals. It can be reproduced with the attached script, which optionally accepts a time parameter, defaulting to 1 ms. With a 75 Hz display mode, screen corruption occurs rather reliably by using a time parameter in the following ranges: 0.000-0.002, 0.011-0.015, 0.024-0.028, 0.038-0.042, 0.051-0.055, 0.064-0.068, 0.078-0.082, 0.091-0.095, 0.104-0.108
However, using sleep times between these intervals, e.g. 0.1, does not produce any screen corruption. For a frequency of 75 Hz the frame time is T = 1000 / 75 ms = 13.3 ms and the screen corruption happens for sleep times of: S = n * T +- 2 ms Here n is a natural number, i.e. 0, 1, 2, 3, and so on.
Linux 4.14 is not affected by this problem, as is noted in comment 93. However, that version only works by accident: When the display mode is not yet known, default parameters, in particular 60 Hz, are used to calculate frame_time_x2 as (1000000 / 60) * 2 / 100 = 333, which is then used to set VBITimeout. Later, when the refresh rate of 75 Hz is known, frame_time_x2 gets updated to 266, but VBITimeout is never actually set to that value via smu7_notify_smc_display.
Linux 4.15 included the DC patches, and when using DC (e.g. by using the boot argument amdgpu.dc=1), VBITimeout is never set to the default 333, but directly to 266, which triggers the screen corruption and flickering problems described in this bug.
With Linux 4.17 the problem got more widespread, because the default was accidentally switched to enable DC by erroneously removing the 'return amdgpu_dc > 0;' line with: commit 367e66870e9cc20b867b11c4484ae83336efcb67 Author: Alex Deucher alexander.deucher@amd.com Date: Thu Jan 25 16:53:25 2018 -0500
drm/amdgpu: remove DC special casing for KB/ML
It seems to be working now.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102372 Reviewed-by: Mike Lothian mike@fireburn.co.uk Reviewed-by: Harry Wentland harry.wentland@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 309977ef5b51..2ad9de42b65b 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -1704,6 +1704,8 @@ bool amdgpu_device_asic_has_dc_support(enum amd_asic_type asic_type) case CHIP_BONAIRE: case CHIP_HAWAII: case CHIP_KAVERI: + case CHIP_KABINI: + case CHIP_MULLINS: case CHIP_CARRIZO: case CHIP_STONEY: case CHIP_POLARIS11: @@ -1714,9 +1716,6 @@ bool amdgpu_device_asic_has_dc_support(enum amd_asic_type asic_type) #if defined(CONFIG_DRM_AMD_DC_PRE_VEGA) return amdgpu_dc != 0; #endif - case CHIP_KABINI: - case CHIP_MULLINS: - return amdgpu_dc > 0; case CHIP_VEGA10: #if defined(CONFIG_DRM_AMD_DC_DCN1_0) case CHIP_RAVEN:
Linux 4.18 aligns the Non-DC case more closely with the DC case and thus VBITimeout gets actually set to the updated frame_time_x2 via smu7_notify_smc_display. Thus the Non-DC case is also affected by this bug since: commit 555fd70c59bc7f7acd8bc429d92bd59a66a7b83b Author: Rex Zhu Rex.Zhu@amd.com Date: Tue Mar 27 13:32:02 2018 +0800
drm/amd/pp: Not call cgs interface to get display info
DC/Non DC all will update display configuration when the display state changed No need to get display info through cgs interface
Reviewed-by: Evan Quan evan.quan@amd.com Signed-off-by: Rex Zhu Rex.Zhu@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com
Linux 4.20 contains a commit trying to fix flickering issues: commit ec2e082a79b5d46addf2e7b83a13fb015fca6149 Author: Alex Deucher alexander.deucher@amd.com Date: Thu Aug 9 14:24:08 2018 -0500
drm/amdgpu/powerplay: check vrefresh when when changing displays
Compare the current vrefresh in addition to the number of displays when determining whether or not the smu needs updates when changing modes. The SMU needs to be updated if the vbi timeout changes due to a different refresh rate. Fixes flickering around mode changes in some cases on polaris parts.
Reviewed-by: Rex Zhu Rex.Zhu@amd.com Reviewed-by: Huang Rui ray.huang@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com
But that doesn't fix the screen corruption described in this bug, because the problem is not that VBITimeout isn't updated enough, but rather the opposite, i.e. that it gets set to the frame_time_x2 value calculated from the correct, high refresh rate instead of the default value of 333.
At least for 75 Hz, this problem can be fixed by preventing frame_time_x2 and thus VBITimeout from being smaller than 280, as in the attached patch. Setting VBITimeout to higher values than the calcualted frame_time_x2 does not seem to cause any problems. It would be great if someone could test this patch with higher refresh rates, as well.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #98 from Ahzo@tutanota.com --- Created attachment 144951 --> https://bugs.freedesktop.org/attachment.cgi?id=144951&action=edit Script to reproduce the problem
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #99 from tempel.julian@gmail.com --- Wow, finally a fix. It seems to work without issues for me now with 2560x1440 75Hz. You're a true hero! =) Will test some higher refreshrates tomorrow, I can overclock my display to 100Hz or higher (at least in theory, I guess DL-DVI pixelclock limitation will limit me to something like 82Hz).
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #100 from timm366@gmail.com timm366@gmail.com --- Ahzo, I also verified your patch using my monitor's max resolution/freq 2560x1440/75Hz (my preferred settings), on Manjaro 5.2.6-arch1-1-custom. Thanks!
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #101 from Maxim Ivanov m.ivanov2k@gmail.com --- (In reply to Ahzo from comment #97)
Created attachment 144950 [details] [review] Patch to fix the problem
TLDR: A script to reproduce and a patch to fix this problem are attached.
The problem occurs when switching between high and low GPU memory frequencies at specific time intervals. It can be reproduced with the attached script, which optionally accepts a time parameter, defaulting to 1 ms. With a 75 Hz display mode, screen corruption occurs rather reliably by using a time parameter in the following ranges: 0.000-0.002, 0.011-0.015, 0.024-0.028, 0.038-0.042, 0.051-0.055, 0.064-0.068, 0.078-0.082, 0.091-0.095, 0.104-0.108
However, using sleep times between these intervals, e.g. 0.1, does not produce any screen corruption. For a frequency of 75 Hz the frame time is T = 1000 / 75 ms = 13.3 ms and the screen corruption happens for sleep times of: S = n * T +- 2 ms Here n is a natural number, i.e. 0, 1, 2, 3, and so on.
Linux 4.14 is not affected by this problem, as is noted in comment 93. However, that version only works by accident: When the display mode is not yet known, default parameters, in particular 60 Hz, are used to calculate frame_time_x2 as (1000000 / 60) * 2 / 100 = 333, which is then used to set VBITimeout. Later, when the refresh rate of 75 Hz is known, frame_time_x2 gets updated to 266, but VBITimeout is never actually set to that value via smu7_notify_smc_display.
Linux 4.15 included the DC patches, and when using DC (e.g. by using the boot argument amdgpu.dc=1), VBITimeout is never set to the default 333, but directly to 266, which triggers the screen corruption and flickering problems described in this bug.
With Linux 4.17 the problem got more widespread, because the default was accidentally switched to enable DC by erroneously removing the 'return amdgpu_dc > 0;' line with: commit 367e66870e9cc20b867b11c4484ae83336efcb67 Author: Alex Deucher alexander.deucher@amd.com Date: Thu Jan 25 16:53:25 2018 -0500
drm/amdgpu: remove DC special casing for KB/ML It seems to be working now. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102372 Reviewed-by: Mike Lothian <mike@fireburn.co.uk> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 309977ef5b51..2ad9de42b65b 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -1704,6 +1704,8 @@ bool amdgpu_device_asic_has_dc_support(enum amd_asic_type asic_type) case CHIP_BONAIRE: case CHIP_HAWAII: case CHIP_KAVERI:
case CHIP_KABINI:case CHIP_MULLINS: case CHIP_CARRIZO: case CHIP_STONEY: case CHIP_POLARIS11:@@ -1714,9 +1716,6 @@ bool amdgpu_device_asic_has_dc_support(enum amd_asic_type asic_type) #if defined(CONFIG_DRM_AMD_DC_PRE_VEGA) return amdgpu_dc != 0; #endif
case CHIP_KABINI:case CHIP_MULLINS:return amdgpu_dc > 0; case CHIP_VEGA10:#if defined(CONFIG_DRM_AMD_DC_DCN1_0) case CHIP_RAVEN:
Linux 4.18 aligns the Non-DC case more closely with the DC case and thus VBITimeout gets actually set to the updated frame_time_x2 via smu7_notify_smc_display. Thus the Non-DC case is also affected by this bug since: commit 555fd70c59bc7f7acd8bc429d92bd59a66a7b83b Author: Rex Zhu Rex.Zhu@amd.com Date: Tue Mar 27 13:32:02 2018 +0800
drm/amd/pp: Not call cgs interface to get display info DC/Non DC all will update display configuration when the display state changed No need to get display info through cgs interface Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>Linux 4.20 contains a commit trying to fix flickering issues: commit ec2e082a79b5d46addf2e7b83a13fb015fca6149 Author: Alex Deucher alexander.deucher@amd.com Date: Thu Aug 9 14:24:08 2018 -0500
drm/amdgpu/powerplay: check vrefresh when when changing displays Compare the current vrefresh in addition to the number of displays when determining whether or not the smu needs updates when changing modes. The SMU needs to be updated if the vbi timeout changes due to a different refresh rate. Fixes flickering around mode changes in some cases on polaris parts. Reviewed-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>But that doesn't fix the screen corruption described in this bug, because the problem is not that VBITimeout isn't updated enough, but rather the opposite, i.e. that it gets set to the frame_time_x2 value calculated from the correct, high refresh rate instead of the default value of 333.
At least for 75 Hz, this problem can be fixed by preventing frame_time_x2 and thus VBITimeout from being smaller than 280, as in the attached patch. Setting VBITimeout to higher values than the calcualted frame_time_x2 does not seem to cause any problems. It would be great if someone could test this patch with higher refresh rates, as well.
Well, people are reporting this patch to be a success. Can you submit this to be reviewed for merging into the kernel? By the way, I have this issue with the amdgpu package, not amdgpu-experimental.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #102 from Maxim Ivanov m.ivanov2k@gmail.com --- I have also compiled a kernel for myself with this patch and I can confirm it is working correctly under amdgpu with my monitor (1920x1080 @ 75Hz) !
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #103 from reject5514@naver.com --- I have this problem on Archlinux 5.2.8-arch1-1-ARCH when connected 2 monitors(1920x1080 @ 60Hz) and amdgpu.ppfeaturemask=0xffffffff option enabled. Patch didn't work for me.
My GPU is RX570.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #104 from Adrian Przekwas adrian.v.przekwas@gmail.com --- The patch fixed the issue for me - Radeon RX 580, 1920x1080@75Hz, connected via DisplayPort.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #105 from magist3r magist3r@gmail.com --- (In reply to reject5514 from comment #103)
I have this problem on Archlinux 5.2.8-arch1-1-ARCH when connected 2 monitors(1920x1080 @ 60Hz) and amdgpu.ppfeaturemask=0xffffffff option enabled. Patch didn't work for me.
My GPU is RX570.
Try this patch: https://lists.freedesktop.org/archives/amd-gfx/2019-June/036022.html
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #106 from reject5514@naver.com --- (In reply to magist3r from comment #105)
(In reply to reject5514 from comment #103)
I have this problem on Archlinux 5.2.8-arch1-1-ARCH when connected 2 monitors(1920x1080 @ 60Hz) and amdgpu.ppfeaturemask=0xffffffff option enabled. Patch didn't work for me.
My GPU is RX570.
Try this patch: https://lists.freedesktop.org/archives/amd-gfx/2019-June/036022.html
That patch solved the issue but memory clock is fixed to maximum state(1750MHz). Normally it should change dynamically.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #107 from magist3r magist3r@gmail.com --- (In reply to reject5514 from comment #106)
(In reply to magist3r from comment #105)
(In reply to reject5514 from comment #103)
I have this problem on Archlinux 5.2.8-arch1-1-ARCH when connected 2 monitors(1920x1080 @ 60Hz) and amdgpu.ppfeaturemask=0xffffffff option enabled. Patch didn't work for me.
My GPU is RX570.
Try this patch: https://lists.freedesktop.org/archives/amd-gfx/2019-June/036022.html
That patch solved the issue but memory clock is fixed to maximum state(1750MHz). Normally it should change dynamically.
That patch only fixes reclocking behaviour with ppfeaturemask=0xffffffff. I have two 75Hz monitors and flickering only appears when I enable OverDrive. And memory clock is ALWAYS fixed to maximum state in my case to (surprise) prevent flickering =).
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #108 from tempel.julian@gmail.com --- I suppose also the Windows driver enforces maximum VRAM clock in your case all the time? If that is true, it would definitely be a cool thing if we could get a patch into upstream to cover that as well (Ahzo's patch landed in amd-staging-drm-next branch).
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #109 from magist3r magist3r@gmail.com --- (In reply to tempel.julian from comment #108)
I suppose also the Windows driver enforces maximum VRAM clock in your case all the time? If that is true, it would definitely be a cool thing if we could get a patch into upstream to cover that as well (Ahzo's patch landed in amd-staging-drm-next branch).
I don't have Windows installed on my machine so I don't know. Anyway the linux driver enforces VRAM clock because of my two monitors are out of sync, and memory reclockimg causes flickering (if I understand correctly what driver's code do). My patch fixes a bug that breaks this behavior when OverDrive mask is enabled, nothing more.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #110 from tempel.julian@gmail.com --- (In reply to magist3r from comment #109)
My patch fixes a bug that breaks this behavior when OverDrive mask is enabled, nothing more.
It unfortunately also forces my single display 1440p 75Hz into maximum VRAM clock.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #111 from magist3r magist3r@gmail.com --- (In reply to tempel.julian from comment #110)
(In reply to magist3r from comment #109)
My patch fixes a bug that breaks this behavior when OverDrive mask is enabled, nothing more.
It unfortunately also forces my single display 1440p 75Hz into maximum VRAM clock.
It's not caused by my patch. Try to disable overdrive mask, revert the patch and you will see the same behavior.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #112 from tempel.julian@gmail.com --- (In reply to magist3r from comment #111)
It's not caused by my patch. Try to disable overdrive mask, revert the patch and you will see the same behavior.
There is dynamic VRAM clocking enabled by default for 1440p 75Hz also without overdrive mask. I haven't tested without overdrive mask and with your patch at the same time, but it should still change clocks regardless.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #113 from Adrian Przekwas adrian.v.przekwas@gmail.com --- (In reply to tempel.julian from comment #108)
I suppose also the Windows driver enforces maximum VRAM clock in your case all the time?
Windows users are reporting max vram clock if 2 (especially high refresh rate or different refresh rate) monitors are connected https://community.amd.com/thread/214915
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #114 from Yuxuan Shui yshuiv7@gmail.com --- (In reply to magist3r from comment #111)
(In reply to tempel.julian from comment #110)
(In reply to magist3r from comment #109)
My patch fixes a bug that breaks this behavior when OverDrive mask is enabled, nothing more.
It unfortunately also forces my single display 1440p 75Hz into maximum VRAM clock.
It's not caused by my patch. Try to disable overdrive mask, revert the patch and you will see the same behavior.
Can confirm your patch fixed the glitch for me. Also yes, my MCLK is stuck at the highest level without your patch anyways.
I have 2 monitors at 60hz.
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #115 from tempel.julian@gmail.com --- There is a new patch series that should allow memclock switching with same refreshrate multi monitor setup: https://lists.freedesktop.org/archives/amd-gfx/2019-August/038995.html
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #116 from tempel.julian@gmail.com --- Ahzo's patch is now merged in drm-next-5.5-wip branch: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.5-wip&id=... Big thanks for including!
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Martin Peres martin.peres@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |MOVED
--- Comment #117 from Martin Peres martin.peres@free.fr --- -- 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/234.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org