Bug 101229

Summary: Global screen tearing (scrolling, Hz miss-match?)
Product: Mesa Reporter: Paul <Paul.Hancock.17041993>
Component: Drivers/Gallium/radeonsiAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact: Default DRI bug account <dri-devel>
Severity: major    
Priority: medium CC: fdsfgs
Version: 17.0   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: glxinfo
xorg
display modes
dmesg | radeon

Description Paul 2017-05-30 06:31:18 UTC
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.
Comment 1 Michel Dänzer 2017-05-30 07:47:20 UTC
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.
Comment 2 Paul 2017-05-30 22:27:27 UTC
Created attachment 131583 [details]
xorg
Comment 3 Paul 2017-05-30 22:28:00 UTC
Created attachment 131584 [details]
display modes
Comment 4 Paul 2017-05-30 22:28:47 UTC
Created attachment 131585 [details]
dmesg | radeon
Comment 5 Paul 2017-05-30 22:41:49 UTC
(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.
Comment 6 Michel Dänzer 2017-05-31 03:30:20 UTC
Which rendering backend and tearing prevention method are selected in the kwin settings?
Comment 7 Paul 2017-05-31 22:16:36 UTC
(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.
Comment 8 Michel Dänzer 2017-06-01 03:13:38 UTC
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
Comment 9 Paul 2017-06-06 01:06:57 UTC
(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.
Comment 10 Michel Dänzer 2017-06-06 01:19:30 UTC
(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.
Comment 11 Paul 2017-06-06 03:51:57 UTC
(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...
Comment 12 Michel Dänzer 2017-06-06 07:17:19 UTC
(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.
Comment 13 Justin Mitzel 2017-09-08 23:43:20 UTC
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.
Comment 14 Michel Dänzer 2017-09-09 06:58:40 UTC
(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?
Comment 15 Michel Dänzer 2017-09-09 06:59:52 UTC
(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?
Comment 16 Justin Mitzel 2017-09-09 16:07:56 UTC
(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.
Comment 17 Paul 2017-09-09 23:11:16 UTC
> 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...
Comment 18 Michel Dänzer 2017-09-10 02:41:35 UTC
(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.
Comment 19 GitLab Migration User 2019-09-25 17:59:06 UTC
-- 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.