Created attachment 131571 [details] glxinfo System exhibits uncontrolled screen-tearing that can be seen when moving windows, watching videos or playing games, or any graphical movement in general. The tearing gradually shifts up or down the screen, suggesting its a cycle frequency miss-match (or floating-point error). Has affected mesa 12 and kernel 4.8 onwards.
Please attach the Xorg log file and the output of xrandr and dmesg corresponding to the problem. Can you create a video demonstrating the problem when moving windows? If not, please describe which desktop environment / window manager / compositing manager you're using.
Created attachment 131583 [details] xorg
Created attachment 131584 [details] display modes
Created attachment 131585 [details] dmesg | radeon
(In reply to Michel Dänzer from comment #1) > Can you create a video demonstrating the problem when moving windows? If > not, please describe which desktop environment / window manager / > compositing manager you're using. Don't think I can show a video as I don't have a high-end camera or capture card, but it affects vanilla Kubuntu 16.10 and 17.04 at least.
Which rendering backend and tearing prevention method are selected in the kwin settings?
(In reply to Michel Dänzer from comment #6) > Which rendering backend and tearing prevention method are selected in the > kwin settings? XRender and auto, I have tried the full-repaint but it didn't seem to have an effect.
To prevent tearing, you need to either choose OpenGL instead of XRender and an appropriate tearing prevention setting, or enable TearFree with xrandr --output eDP --set TearFree on
(In reply to Michel Dänzer from comment #8) > To prevent tearing, you need to either choose OpenGL instead of XRender and > an appropriate tearing prevention setting, or enable TearFree with > > xrandr --output eDP --set TearFree on it's less obvious, but there still appears to be screen tearing when running via openGL 3.1 using full-screen-repaints. It's also reasonably obvious that for some GUIs their buttons will update their two triangles across two frames instead of one, this seems to be a much rarer occurrence with the above settings however.
(In reply to Paul from comment #9) > it's less obvious, but there still appears to be screen tearing How does that manifest, and when you do what? > when running via openGL 3.1 using full-screen-repaints. FWIW, since DRI3 is enabled, "Re-use screen content" is the most efficient setting. > It's also reasonably obvious that for some GUIs their buttons will update > their two triangles across two frames instead of one, this seems to be a > much rarer occurrence with the above settings however. Yeah, this is unavoidable with apps which use X11 drawing primitives targeting their windows directly.
(In reply to Michel Dänzer from comment #10) > (In reply to Paul from comment #9) > > it's less obvious, but there still appears to be screen tearing > > How does that manifest, and when you do what? Use the system and run OpenGL applications, is there an option to enable triple-buffering or is it enabled by default? > FWIW, since DRI3 is enabled, "Re-use screen content" is the most efficient > setting. I did have this enabled for a while, but plasma got super erratic after I had launched a game, I'll give it another shot and see if it does it again. I'm also going to try with 'allow applications to disable composition' unchecked in case something was disabling the compositor...
(In reply to Paul from comment #11) > Use the system and run OpenGL applications, Fullscreen or windowed? Does enabling any sync-to-vblank functionality in the apps or setting the environment variable vblank_mode=3 for running them help? > is there an option to enable triple-buffering or is it enabled by default? Automatically used with DRI3.
I've also had this problem, I'm using the AMDGPU-experimental option that i've enabled in the kernels because I'm on a R9 390x. I'm in Mesa 17.1 on Kernel 4.12.11 in KDE Manjaro Linux. I am using a display port and this happens both at 144hz and 60hz. I've tried recording it using OBS, however, it did not show up in the video. I've also tried using compton and enabling full-screen reprints. Compton did not help at all, and enabling full-screen reprint v-sync helped a small amount but did not stop it from happening. Switching between Kwin and OpenGL 3.1 did not change anything.
(In reply to Justin Mitzel from comment #13) > I've also had this problem, How do you know it's the same problem? I still don't have a good idea what the problem reported here looks like (and my last questions from comment 12 are unanswered). > I've tried recording it using OBS, however, it did not show up in the video. Can you take an external video (e.g. using a cell phone) demonstrating the problem?
(In reply to Paul from comment #0) > Has affected mesa 12 and kernel 4.8 onwards. BTW, Paul, does this mean that the problem doesn't occur if you use Mesa < 12 or kernel < 4.8? If so, can you bisect Mesa or the kernel?
(In reply to Michel Dänzer from comment #14) > How do you know it's the same problem? I still don't have a good idea what > the problem reported here looks like (and my last questions from comment 12 > are unanswered). I suppose that is a good point. I don't really know but I figured it sounds very similar. I also figured that posting here would be better than making a new bug report. > > I've tried recording it using OBS, however, it did not show up in the video. > > Can you take an external video (e.g. using a cell phone) demonstrating the > problem? Here is a cellphone capture of the screen-tearing I'm talking about in Stardew Valley. It is mostly happens indoors, and happens outdoors occasionally. https://vid.me/n0t1r It also happens on the desktop sometimes, although (most likely) too rarely for me to capture. It also happens this noticeably in Torchlight II, if you would want me to record that as well.
> https://vid.me/n0t1r Ok, that 'tearing' is in fact much different to what I've been seeing, in your case it looks a lot more like *corruption* as entire chunks of buffer are being rendered in random offset positions. I dont really know exactly what might cause this, but I do know that running applications in fullscreen at a different resolution to native can result in various buffer corruption... (In reply to Michel Dänzer from comment #12) > (In reply to Paul from comment #11) > > Use the system and run OpenGL applications, > > Fullscreen or windowed? Does enabling any sync-to-vblank functionality in > the apps or setting the environment variable vblank_mode=3 for running them > help? Windowed, I rarely run things in fullscreen, of which it's usually borderless windowed anyway. I don't remember if setting the vblank mode actually worked though...
(In reply to Justin Mitzel from comment #16) > I also figured that posting here would be better than making a new bug report. I'm afraid that was the wrong call, please file your own report. In general, it's easy to mark duplicate bug reports, but it's hard to untangle information about different problems in a single report, so it's better to start with a separate report unless one is at least 99% sure it's exactly the same problem. Also, lots of different causes can produce similar symptoms. > Here is a cellphone capture of the screen-tearing I'm talking about in > Stardew Valley. BTW, that's not what "tearing" refers to in the display context.
-- 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/mesa/mesa/issues/1267.
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.