Created attachment 111427 [details] video screenshot of the glitch When I enable 120Hz refresh rate in the Radeon R9 290 card, with my Benq XL2420T monitor, I get horizontal glitches in the image. That happens in KDE, Unity, XFCE (all with or without compositing), and games. Without compositing, the windows decorations in KDE show artifacts in 60 and 120Hz. 60Hz refresh rate works okay. Fglx proprietary driver works okay with 120Hz. I also have a Radeon HD 6970 with the radeon OSS driver and it also works okay in 120Hz in my system. Currently I am using Kubuntu 14.10, kernel 3.19RC1 and Mesa git from this PPA: https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa The card is a Sapphire Radeon R9 290 4GB Tri-X. This bug is happening since I got this card, in September. I cant get a direct screenshot nor taking photos (with a smartphone) of the glitch happening, so I take a video of it with a phone and then take a screenshot.
Please attach /var/log/Xorg.0.log and the output of dmesg. Can you upload the video somewhere? If not, please provide more details about the glitches, e.g.: Are they always visible, or only intermittently? If the latter, how often? Does the vertical location of the glitches change or is it always the same? ...
Same here with my gigabyte r9 290. The glitches pop up randomly. Here is the video http://youtu.be/ilH6em3eIrY
(In reply to Sandro from comment #2) > Same here with my gigabyte r9 290. > The glitches pop up randomly. > Here is the video http://youtu.be/ilH6em3eIrY The link says the video is private.
(In reply to Alex Deucher from comment #3) > (In reply to Sandro from comment #2) > > Same here with my gigabyte r9 290. > > The glitches pop up randomly. > > Here is the video http://youtu.be/ilH6em3eIrY > > The link says the video is private. try now
Yes, it seems to work now.
Created attachment 112180 [details] dmesg
Created attachment 112181 [details] /var/log/Xorg.0.log
(In reply to Michel Dänzer from comment #1) > Please attach /var/log/Xorg.0.log and the output of dmesg. > > Can you upload the video somewhere? > > If not, please provide more details about the glitches, e.g.: Are they > always visible, or only intermittently? If the latter, how often? Does the > vertical location of the glitches change or is it always the same? ... I set the 120Hz and restarted. Then I opened Konsole and got the results and put then as attachments. Finally got a video and put it in Youtube: https://www.youtube.com/watch?v=W7a9nrwPPeY I cant get the video with tools like Kazam or SimpleScreenRecorder. I have to grab it with a external camera. The glitches are intermittently. The image cam be fine for a fell seconds then the glitches show themselves.
(In reply to Clésio Luiz from comment #8) > I cant get the video with tools like Kazam or SimpleScreenRecorder. I have > to grab it with a external camera. I mean, the glitches don't appear in the video files created with the above tools, for some reason. The only way to show you guys the problem is to record it with a external camera.
It looks like maybe the dpm memory reclocking occasionally misses the vblank. Do you still get the glitches if you connect a secondary display or disable dynamic clocking? To disable able dynamic clocking (as root): echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level to re-enable it (as root): echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level
(In reply to Alex Deucher from comment #10) > It looks like maybe the dpm memory reclocking occasionally misses the > vblank. Do you still get the glitches if you connect a secondary display or > disable dynamic clocking? To disable able dynamic clocking (as root): > echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level > to re-enable it (as root): > echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level The High value makes the glitches go away. As soon as I set the Auto value, the glitches reappear. I don't have access to a second display to test right now, only tomorrow.
glitches disapper from me too with 'high' parameter.
I have a somewhat similar issue with radeonsi, latest everything (xorg, llvm, mesa) except Linux kernel which is 3.17.8, and Cape Verde PRO (aka Radeon HD 7750) hardware. The screen sometimes turns completely black for a frame. It happened a few times per hour. In the past this could be reliably avoided by pinning the power setting to min or max, but DPM changes prevented that fix from working. Now that I know this: echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level (looks similar to the one that used to work a few kernels earlier?) I can avoid the problem again, but of course at the cost of power consumption. The underlying issue might be the same timing problem. I can file a new bug if you think it is a different issue.
I tested now with 2 displays, the Benq monitor (DVI cable) at 120Hz and a Lg TV (HDMI cable) and the glitches disappear. When I disable the TV (from System Settings) and disconnect the cable, the glitches are still gone. Only when I restart the system the glitches come back. I should mention that any refresh rate above 60Hz triggers the problem, not only 120Hz.
Created attachment 112228 [details] [review] add some debugging output Based on the timing for the 1920x1080@120 timing from your xorg log, it looks like it should be just under the switch limit. Can you apply the attached patch and switch to the problematic mode and then attach your dmesg output so I can see what's happening?
I didn't compiled the driver myself, got it from a repository. I'm afraid that applying a patch and compile the driver is out of my knowledge... But I'm more than happy to follow instructions.
(In reply to Clésio Luiz from comment #16) > I didn't compiled the driver myself, got it from a repository. I'm afraid > that applying a patch and compile the driver is out of my knowledge... But > I'm more than happy to follow instructions. If you can download the source to your kernel, copy the patch to the root of the kernel tree then do the following: patch -p1 -i dpm_vblank_dump.diff make -j5 sudo make modules_install sudo make install Then reboot and select the new kernel from the grub menu.
*** Bug 89198 has been marked as a duplicate of this bug. ***
Created attachment 113617 [details] [review] fix 1/2 The attaches patches should fix the issue, but I would still like to get the output of the debugging patch in comment 15 so that I can fine tune things if possible.
Created attachment 113618 [details] [review] fix 2/2 Please apply both patches.
I'm still having this issue. Here's some dmesg output: [ 363.951100] -- 2560x1440 -- [ 363.951101] radeon_crtc->hw_mode.crtc_htotal: 2640 [ 363.951101] radeon_crtc->hw_mode.clock: 482640 [ 363.951102] radeon_crtc->hw_mode.crtc_vblank_end: 1525 [ 363.951102] radeon_crtc->hw_mode.crtc_vdisplay: 1440 [ 363.951103] radeon_crtc->v_border: 0 [ 363.951103] vblank_time_us: 425 [ 363.951104] vblank_lines: 85 [ 363.951104] line_time_us: 5 [ 363.951105] vblank_time: 425, switch_limit: 450
(In reply to Andreas Gihr from comment #21) > I'm still having this issue. Does it still happen with the patches applied?
I'm using the newest kernel from git. It said: Reversed (or previously applied) patch detected!
Created attachment 114443 [details] [review] possible fix Does this patch on top of latest git help?
It didn't help.
Created attachment 114452 [details] [review] possible fix Does this patch against latest git help?
Yes it helps. Thanks.
But now there is much higher power consumption in idle.
The bug seems to be gone for me. Using Kernel 4.0 RC7 and latest Paulo Dias Mesa git PPA. Temperature of the GPU appears to be normal at idle.
After reading the Andreas Gihr post about greater power consumption, I did a little test. Using Kubuntu KDE 4 I put the display at 60Hz and watched the GPU temperature drop 3°C. Put it back at 120Hz and the temp go up the same 3°C. But to me, this is expected. The GPU is working more to double the FPS of the KDE compositing. So is natural it getting hotter.
The power consumption rises about 40 watts at 120hz. This is the case in KDE and in Openbox without compositing. In Windows there's about 1 watt difference.
-- 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/567.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.