Enable DRI3 by default in 18.04?

[Wimpress]

I propose that DRI3 be enabled by default in 18.04 so that screen tearing is mitigated for Xorg users.

I regularly see people seeking ways to eliminate screen tearing on various Ubuntu flavours. DRI3 has been disabled in Ubuntu for some years now and enabling it by default was requested soon after it was disabled. Are the reasons for disabling DRI3 still valid? Is it time to enable DRI3 by default now that Vulkan is an established technology?

Tagging those who know better than I if this proposal is sane @raof @3v1n0 @greyback @robert.ancell @willcooke

[vanvugt]

Worth noting that in the default Wayland session “Ubuntu”, Xwayland only offers DRI3 support. No DRI2. There it seems to be pretty solid thanks to Mesa being kept in step with it. DRI3 only caused issues for libva which can only do DRI2. So I guess just make sure xdpyinfo is telling you that both are supported and not just one, or else you will lose accelerated video decoding in your Xorg sessions.

Your justification for wanting DRI3 “to eliminate screen tearing” doesn’t sound right though. We fixed tearing in Ubuntu (using DRI2) years ago. The correct fix is to get your compositor to use proper fullscreen buffer swapping that is synchronized to vblank. And compiz has done that by default since ~2012. It sounds like you’re using something that’s not Gnome/Unity/Compiz?..

Caveat: Fullscreen apps may tear in Unity/Compiz still because of the Xorg architecture. We prefer performance over having an extra level of indirection. But you can fix that tearing in CompizConfig Settings Manager > General > Composite > and adding the app to the filter that doesn’t get “unredirected”. So Compiz then handles it and avoids tearing in your fullscreen app.

[vanvugt]

Also, DRI3 is already enabled by default in both Xorg and Wayland sessions. You can check this with:

xdpyinfo | grep DRI

See also: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1441951/comments/7

[william-1986]

Hi, I’m no expert in the technology but this is a vital part (IMHO) of improving UX - also, as a permanent migraine sufferer, a tear-free experience goes a long way. I have not tested 17.10 in depth to see this by default so I apologise for leaping in here when it may be a non-issue.

Having said that, the information from these links helped me correct screen tearing in 16.04 using Intel, AMD, and nvidia graphics on four separate machines:

Intel / nvidia
http://askubuntu.com/questions/667466/screen-tearing-in-ubuntu-with-nvidia-intel-graphics

Intel
https://wiki.archlinux.org/index.php/Intel_graphics#Tear-free_video

AMD

Eliminate screen tearing with AMD GPU on Ubuntu

[vanvugt]

This is concerning for me. Back in 2012 I spent a lot of time eliminating tearing for good on Ubuntu desktop. So I’m surprised to hear that anyone still has issues today. But let’s fix this…

If you experience tearing in 17.10/18.04 then please log a bug in Launchpad and subscribe me (vanvugt). The links you mention are a bit old and refer to things that are outdated so we should take a fresh look. I hope we can fix most of this before 18.04.

As for the topic of “DRI3”, that is already enabled by default in both Xorg and Wayland sessions. So we should probably end this topic and look at particular cases of tearing as formal bug reports.

[william-1986]

Hi, sorry for taking so long to reply. As a rule I tend to stick to the LTS for my main machine - I’m on elementary and have been for a while (purely to stop me tinkering too much) - but I have another laptop that I use for testing/casual gaming and I plan to install vanilla Ubuntu onto it after I’ve dealt with a few household things. The night light feature is something I plan to make use of for my migraines so this will get a lot of use.

Thanks for your help, I’ll be sure to drop any information I come across into Launchpad as you suggest.

[Wimpress]

@vanvugt Sorry for the delay in reply. I’ve had some annual leave and been busy on other tasks.

Anyway, I’ve just installed Ubuntu MATE 18.04 daily on one of my test laptops. Here is the relevant information:

Graphics:  Card: Intel HD Graphics 5500
           Display Server: x11 (X.Org 1.19.5 )
           drivers: modesetting (unloaded: fbdev,vesa)
           Resolution: 1920x1080@60.00hz
           OpenGL: renderer: Mesa DRI Intel HD Graphics 5500 (Broadwell GT2)
           version: 4.5 Mesa 17.2.2

The output of xdpyinfo | grep DRI gives the following:

    DRI2
    DRI3

The output of grep DRI /var/log/Xorg.0.log implies that DRI2 is being used?

[     6.228] (II) glamor: EGL version 1.4 (DRI2):
[     6.422] (II) modeset(0): [DRI2] Setup complete
[     6.422] (II) modeset(0): [DRI2]   DRI driver: i965
[     6.422] (II) modeset(0): [DRI2]   VDPAU driver: i965
[     6.436] (II) GLX: Initialized DRI2 GL provider for screen 0

And more confusingly LIBGL_DEBUG=verbose glxinfo | grep libgl reports:

libGL: Using DRI3 for screen 0

I’m not familiar enough with DRI and KMS to understand why DRI2 and DRI3 are being reported by different tools? Can you help clear up my confusion?

Marco, the MATE Desktop Window Manager, supports the Present extension which in turn requires DRI3. I can confirm that on this laptop I am not experiencing any screen tearing when running glxgears -fullscreen with the default configuration. Ubuntu MATE also support Compiz, and again, no screen tearing on this laptop using the default configuration.

I have some newer laptops that I’m sure are/were exhibiting screen tearing under the same conditions. I’ll run some tests and post feedback here.

[Wimpress]

I have two laptops with the same CPU package, both exhibit significant screen tearing when running glxgears -fullscreen using Marco using and the default configuration on Ubuntu MATE 18.04 daily. Compiz doesn’t exhibit any screen tearing when running glxgears -fullscreen on the same default configuration. Here are the details:

Graphics:  Card: Intel Device 5926
           Display Server: x11 (X.Org 1.19.5 )
           drivers: modesetting (unloaded: fbdev,vesa)
           Resolution: 1920x1080@59.93hz
           OpenGL: renderer: Mesa DRI Intel Iris Plus Graphics 640 (Kaby Lake GT3)
           version: 4.5 Mesa 17.2.2

The output of xdpyinfo | grep DRI gives the following:

    DRI2
    DRI3

The output of grep DRI /var/log/Xorg.0.log shows that DRI2 is being used:

[     6.228] (II) glamor: EGL version 1.4 (DRI2):
[     6.422] (II) modeset(0): [DRI2] Setup complete
[     6.422] (II) modeset(0): [DRI2]   DRI driver: i965
[     6.422] (II) modeset(0): [DRI2]   VDPAU driver: i965
[     6.436] (II) GLX: Initialized DRI2 GL provider for screen 0

And LIBGL_DEBUG=verbose glxinfo | grep libgl reports:

libGL: Using DRI3 for screen 0

However, screen tearing can be completely eliminated by creating /usr/share/X11/xorg.conf.d/20-intel.conf with the following contents:

Section "Device"
    Identifier "Intel Graphics"
    Driver "intel"
EndSection

This forces the use of the intel driver rather than modesetting which was made the default in 16.10 I believe.
After a reboot xdpyinfo | grep DRI and LIBGL_DEBUG=verbose glxinfo | grep libgl report the same as before but grep DRI /var/log/Xorg.0.log now reports:

[     5.033] (II) intel(0): [DRI2] Setup complete
[     5.033] (II) intel(0): [DRI2]   DRI driver: i965
[     5.033] (II) intel(0): [DRI2]   VDPAU driver: va_gl
[     5.033] (II) intel(0): direct rendering: DRI2 DRI3 enabled
[     5.079] (II) GLX: Initialized DRI2 GL provider for screen 0

So DRI3 is shown to be enabled now. Running glxgears -fullscreen using either Marco or Compiz is entirely tear free. Perhaps this suggests the modesetting driver is not able to provide a tear free experience on some devices?

[Wimpress]

I did a little bit of digging and noticed Fedora carry some interesting patches for Xorg with one that looks related that Debian/Ubuntu includes too.

This patch in Fedora appears related to the issue I’m seeing:

• 0001-xf86-dri2-Use-va_gl-as-vdpau_driver-for-Intel-i965-G.patch

I’m building xorg-server for bionic with that patch included to see if it helps…

EDIT: The patches applied cleanly and xorg-server builds successfully. On the computers I’ve been testing with grep DRI /var/log/Xorg.0.log now reports:

[     6.597] (II) modeset(0): [DRI2]   DRI driver: i965
[     6.597] (II) modeset(0): [DRI2]   VDPAU driver: va_gl

Where it previously reported, what I understand to be incorrect:

[     6.422] (II) modeset(0): [DRI2]   DRI driver: i965
[     6.422] (II) modeset(0): [DRI2]   VDPAU driver: i965

[arvidjaar-s]

Well, I have https://bugs.launchpad.net/ubuntu/+source/xorg-server-hwe-16.04/+bug/1665850 opened for months - finally I tracked it down to DRI2 vs DRI3. In this case I have tearing (and other screen corruptions) with DRI3 enabled under 16.04 + HWE. With exactly the same drivers disabling DRI3 eliminates them. This is on HD5500. And screen corruptions happen under normal desktop, nothing about full screen applications.

[vanvugt]

Sorry for the delay. I too have been on holiday

Good news: I can explain just about everything you have described. It’s something I worked on in Compiz around 2011-2012. So let’s see if I remember…

The tearing of glxgears in fullscreen mode is because Compiz is unredirecting it, and DRI2 will tear for DRI2 apps that don’t sync to vblank manually (not that they should need to though). The workaround Compiz uses to avoid most other major fullscreen apps from tearing is to disallow them to unredirect (although this has a performance penalty so swings and roundabouts). You can add glxgears to the list of apps to not unredirect in fullscreen mode, and hence not to tear, in ccsm > Composite > Unredirect Match.

Why DRI2 tears for fullscreen windows that are unredirected, I don’t know. But I do know it’s a problem, which is why I added the “Unredirect Match” option. Certainly when I implemented the same fullscreen bypass/unredirect feature in Mir there was no reason for it to ever tear. And it sounds like DRI3 is just as sensible.

So yes, perhaps using DRI3 might avoid tearing visible in some fullscreen apps. I don’t know how to force it other than fiddling with driver options as you have. Worth noting however that you made a mistake in reasoning above when you mistook the log message “intel(0): direct rendering: DRI2 DRI3 enabled” for DRI3 being enabled. The log message is purely decoration and not relevant. Ask only “xdpyinfo | grep DRI” and you will find it was already available. It’s actually Mesa (libGL*) that decides whether to use the DRI2 or DRI3 interfaces at runtime.

P.S. glxgears uses a very old mechanism for going fullscreen. It does not set the modern window management flag for fullscreen but instead just tries to resize and place itself over the whole screen. For this reason you might find that Unity and Gnome Shell don’t honour it correctly. It’s a very old-fashioned way of going fullscreen so not surprising if it only works as expected in MATE (and thus the tearing only occurs there).

[sudopluto]

At least on optimus systems, the use of the intel driver + tearfree option is needed, as modesetting does not have a tear free option. Out of the box with intel gpu active, Ubuntu has horrible screen tearing on fullscreen applications, where composting is disabled.

Edit:

See this - https://askubuntu.com/questions/667466/screen-tearing-in-ubuntu-with-nvidia-intel-graphics

[vanvugt]

Thanks. That’s a different tearing issue though.

It’s worth noting we’ve been talking about two separate tearing issues so far:

1. Desktop/windowing tearing. This was generally fixed a few years ago, except for Optimus apparently.
2. Per-window tearing for some fullscreen apps only, like glxgears in MATE. This tearing is expected from the fullscreen unredirection optimization and can be fixed with “ccsm > Composite > Unredirect Match” as mentioned above (which will reduce performance).
3. And something we haven’t covered yet: With multiple monitors/outputs, Xorg can only avoid tearing on one of them. Perhaps this is related to the Optimus issue?

So it sounds like this is all understood and the only unexpected tearing issue is when using Optimus+modesetting driver. Please log a bug for that.

[sudopluto]

Woah, thanks for the speedy reply. Can you point me to the proper location to file a bug for the screen tearing with optimus? I am a bit unfamiliar with launchpad / which package this bug is relevant to.

[vanvugt]

Ideally, please use this command to log a bug against the binary package that contains the modesetting driver:
$ ubuntu-bug xserver-xorg-core

But if that fails for any reason then log a bug against the source package here:
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+filebug

Here’s how I found the package names:

$ find /usr -name \*modesetting\*
/usr/lib/xorg/modules/drivers/modesetting_drv.so
/usr/share/man/man4/modesetting.4.gz
$ dpkg -S /usr/lib/xorg/modules/drivers/modesetting_drv.so
xserver-xorg-core: /usr/lib/xorg/modules/drivers/modesetting_drv.so
$ dpkg -s xserver-xorg-core | grep Source
Source: xorg-server

[tjaalton]

if you want tearfree support in modesetting_drv.so then that’s already well known upstream too, just not fixed and looks like it won’t be anytime soon

https://bugs.freedesktop.org/show_bug.cgi?id=98876