Screen tearing in 16.10 onwards

Bug #1694367 reported by Paul
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mesa
Unknown
High
linux (Ubuntu)
Incomplete
Undecided
Unassigned
mesa (Ubuntu)
New
Undecided
Unassigned

Bug Description

In 16.10 onwards my laptop has always shown screen tearing globally, additionally GL applications will not v-sync despite attempting to, they appear to sync slightly off from the [integrated] display.

This occurs with kernels 4.8 to 4.11 and mesa 12 to 17, so not entirely sure if it's a bug with either or a default miss-configuration in ubuntu...

ubuntu-bug also appears to be broken...

Tags: yakkety
Revision history for this message
In , Paul (paul17041993) wrote :

Created attachment 131571
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.

Revision history for this message
In , Michel Dänzer (michel-daenzer) wrote :

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.

Revision history for this message
In , Paul (paul17041993) wrote :

Created attachment 131583
xorg

Revision history for this message
In , Paul (paul17041993) wrote :

Created attachment 131584
display modes

Revision history for this message
In , Paul (paul17041993) wrote :

Created attachment 131585
dmesg | radeon

Changed in mesa:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Paul (paul17041993) wrote :

(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.

Revision history for this message
In , Michel Dänzer (michel-daenzer) wrote :

Which rendering backend and tearing prevention method are selected in the kwin settings?

Revision history for this message
In , Paul (paul17041993) wrote :

(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.

Revision history for this message
In , Michel Dänzer (michel-daenzer) wrote :

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

Revision history for this message
In , Paul (paul17041993) wrote :

(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.

Revision history for this message
In , Michel Dänzer (michel-daenzer) wrote :

(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.

Revision history for this message
In , Paul (paul17041993) wrote :

(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...

Revision history for this message
In , Michel Dänzer (michel-daenzer) wrote :

(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.

Revision history for this message
In , Katoflip (katoflip) wrote :

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.

Revision history for this message
In , Michel Dänzer (michel-daenzer) wrote :

(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?

Revision history for this message
In , Michel Dänzer (michel-daenzer) wrote :

(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?

Revision history for this message
In , Katoflip (katoflip) wrote :

(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.

Revision history for this message
In , Paul (paul17041993) wrote :

> 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...

Revision history for this message
In , Michel Dänzer (michel-daenzer) wrote :

(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.

Changed in mesa:
importance: Medium → High
Revision history for this message
In , Gitlab-migration (gitlab-migration) wrote :

-- 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.

Changed in mesa:
status: Confirmed → Unknown
Juhani Numminen (jsonic)
affects: kernel-package (Ubuntu) → linux (Ubuntu)
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1694367

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
tags: added: yakkety
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.