New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for XPresent extension #350

Closed
wants to merge 6 commits into
base: master
from

Conversation

Projects
None yet
7 participants
@vkareh
Member

vkareh commented Sep 24, 2017

This change adds (optional) support for XPresent to Marco. This should solve tearing for non-proprietary Nvidia drivers.

In addition, depending on what version of x11proto-present headers your system has, for 64-bit systems, Window XIDs get encoded incorrectly and cause XPresent to error out. The code takes that into account and will automatically disable XPresent from the current session so that windows will render without freezing the display.

A lot of inspiration was taken from:

Fixes #326

@Sunderland93

This comment has been minimized.

Sunderland93 commented Sep 25, 2017

Very cool!!! Thanks! I'll test it evening

@Sunderland93

This comment has been minimized.

Sunderland93 commented Sep 25, 2017

I build Marco 1.19 with XPresent patches and run it on Ubuntu MATE 17.10. DRI3 is disabled by default, so I turn it ON in xorg.conf. But tearing is still here, and screen is flickering after minimize windows. Here Xorg log https://pastebin.com/TbtE80Df

@Sunderland93

This comment has been minimized.

Sunderland93 commented Sep 25, 2017

@Sunderland93

This comment has been minimized.

Sunderland93 commented Sep 25, 2017

I will test on Intel and Radeon later

@Sunderland93

This comment has been minimized.

Sunderland93 commented Sep 26, 2017

Ok, tested on Radeon HD7770. Ubuntu MATE 17.10, DRI3 enabled. XPresent not working :( Error: https://pastebin.com/jrzUd4Rs

"XPresent is not compatible with your current system configuration." And many graphical bug's: flickering windows, panel, disappearing wallpaper

@vkareh

This comment has been minimized.

Member

vkareh commented Sep 26, 2017

@Sunderland93 - yeah, that probably means you're on a 64-bit system with an older version of x11proto-present, which means that the window XIDs get encoded incorrectly and XPresentPixmap errors out with BadWindow... As far as I know, the only solution is to make sure that your presentproto headers have this patch on them: https://cgit.freedesktop.org/xorg/proto/presentproto/commit/?id=8405ee4552565825d776e6a8963d33d9cd9cddf0 and then recompile libxpresent to use that new header. I haven't tried this yet, though.

Although this was fixed a while ago, but I don't know if libxpresent is currently compiled with that version. @flexiondotorg - how can we check which version of presentproto was libxpresent compiled with for 17.10? It should be whatever version is on the repo itself, right?

My 64-bit laptop (with Intel graphics) gives me the same error. My 32-bit desktop (with Nvidia graphics) works perfectly well now, and tearing is gone. I will recompile libxpresent and test on my side...

Also interesting is that you got a BadRegion error... I'll take a look at that and try to determine why.

Thanks for testing! 🙂

@Sunderland93

This comment has been minimized.

Sunderland93 commented Sep 26, 2017

@vkareh version of x11proto-present-dev-1.1 in Ubuntu 17.10 archive already has this patch. libxpresent probably compiled with it

@vkareh

This comment has been minimized.

Member

vkareh commented Sep 26, 2017

agreed - I'll set up a 32-bit vm on my laptop to see what happens there.

@Sunderland93

This comment has been minimized.

Sunderland93 commented Sep 26, 2017

Hmm.....on Debian Testing x64 + Nouveau, XPresent works very well. Tearing is gone. x11-proto-present-1.1 and libxpresent-1.0.0

@vkareh

This comment has been minimized.

Member

vkareh commented Sep 26, 2017

That's encouraging!

@vkareh

This comment has been minimized.

Member

vkareh commented Sep 26, 2017

Okay, I finally tested on my laptop (64-bit, Intel graphics) running a 32-bit VM (qemu-i386, with the vmware vga driver) and the tearing inside the VM went away with XPresent. In fact, the fps increased significantly in glxgears (from ~60fps to ~90fps, fullscreen) - running much more smoothly than without XPresent. So this is great news, although it's a contrived environment anyway.

The exact same VM setup, on the same laptop, but running qemu-x86_64 (with the corresponding 64-bit image) still gives me the BadWindow error (that leads to the "XPresent is not compatible with your current system configuration." message). My windows, panels, and background don't flicker in either case.

Edit: If I run the 32-bit version of Ubuntu MATE with qemu-x86_64, XPresent doesn't fail, but tearing is still present. fps still go up on glxgears with XPresent

@vkareh

This comment has been minimized.

Member

vkareh commented Oct 2, 2017

To recap the current state of things:

  • 32-bit Ubuntu, Nvidia: Works!
  • 32-bit Ubuntu (vm), Intel: Works!
  • 64-bit Ubuntu, Intel: not compatible
  • 64-bit Ubuntu (vm), Intel: not compatible
  • 64-bit? Ubuntu, Radeon: not compatible
  • 64-bit Debian, Nvidia: Works!

Also, I tried recompiling present headers and lib, and no change. I haven't recompiled X itself.

I've been researching as much as I can and all I can find is that differences in the various video graphics chips can play a role. Also how the module is being loaded, and whether the card/driver supports DRI3.

I'll install Debian Testing (64-bit) and see if it works on my Intel laptop - then we can blame 64-bit Ubuntu for being the common denominator here 😈

FWIW, the xfwm4 team seems to have run into similar issues, which is why they added the logic to disable XPresent if it the current system configuration doesn't support it (I've added that to the patch as well).

At this point we might just need a larger sample size to ensure that at worst, XPresent just gets disabled without any adverse effects.

I'll report back as soon as I've tested on Debian

@vkareh

This comment has been minimized.

Member

vkareh commented Oct 3, 2017

Update: I'm having a hard time enabling DRI3 on Debian Testing running inside QEMU, but the XPresent extension loaded just fine and did not cause the BadWindow error (that seems to be an Ubuntu 64-bit only issue so far).

Any idea why only Ubuntu 64-bit is causing BadWindow errors when calling XPresentPixmap?

@raveit65

This comment has been minimized.

Member

raveit65 commented Oct 10, 2017

Can someone provide simple steps for testing?
I have no idea to enable DRI3 for example.
I can test it with nvidia-340xx on my mainbox, with intel on my laptop , and with qemu graph drivers in VMs.
Thanks.

Edit:
Btw. where do you see the tearing ? :-)

@Sunderland93

This comment has been minimized.

Sunderland93 commented Oct 11, 2017

@raveit65 just build Marco from vkareh:present branch, install it and exec marco --replace. DRI3 enabled by default on Debian and Fedora, on Ubuntu you need to create (for Intel, for example) /etc/X11/xorg.conf.d/20-intel.conf and put there:

Section "Device"
       Identifier  "Intel Graphics"
       Driver   "modesetting"
       Option  "DRI3"  "true"
EndSection

On Nvidia with proprietary drivers XPresent doesn't work.

@raveit65

This comment has been minimized.

Member

raveit65 commented Oct 23, 2017

@vkareh
For testing the PR i need to know how to reproduce the tearing?

@vkareh

This comment has been minimized.

Member

vkareh commented Oct 23, 2017

@raveit65 - the easiest way I've found is running glxgears -fullscreen you would notice it as a horizontal "cut" in the image visible for a split second, flickering many times throughout the animation. How bad, or whether you're able to see it depends on many factors, like your video card, drivers, screen refresh rate, position of the moon, and whether your cup of tea is half empty or half full 😛

It should look roughly like this:

@vkareh

This comment has been minimized.

Member

vkareh commented Oct 23, 2017

@monsta, @raveit65 - as promised, I just updated this PR with stricter logic in case Marco is compiled without XPresent support. This fixes that strange BadRegion error that was happening earlier

@pasikarkkainen

This comment has been minimized.

pasikarkkainen commented Oct 24, 2017

If I understand correctly currently to enable or disable XPresent feature in Marco one should tweak xorg.conf:
Option "DRI3" "true" or "false", but that obviously disables/enables whole DRI3 support in Xorg server.

I wonder if it'd be good to have a Marco command line option to enable or disable only the XPresent feature in Marco, no matter if underlying Xorg server has DRI3 enabled or disabled? Is that needed?

@raveit65

This comment has been minimized.

Member

raveit65 commented Oct 24, 2017

Ok, here are my results with f26 in qemu-kvm VM.

with virtio (3D acceleration) driver (1920x1080) tearing
without XPresent
[rave@f26 ~]$ glxgears -fullscreen
112 frames in 5.0 seconds = 22.246 FPS
121 frames in 5.0 seconds = 24.198 FPS
116 frames in 5.0 seconds = 23.126 FPS
117 frames in 5.0 seconds = 23.237 FPS
116 frames in 5.0 seconds = 23.088 FPS
116 frames in 5.0 seconds = 23.020 FPS
123 frames in 5.0 seconds = 24.445 FPS
116 frames in 5.0 seconds = 23.171 FPS
114 frames in 5.0 seconds = 22.734 FPS

with virtio (3D acceleration) driver (1920x1080) maybe without tearing, not sure.
with XPresent
[rave@f26 ~]$ glxgears -fullscreen
141 frames in 5.1 seconds = 27.881 FPS
141 frames in 5.0 seconds = 28.153 FPS
128 frames in 5.0 seconds = 25.540 FPS
140 frames in 5.0 seconds = 27.887 FPS
143 frames in 5.0 seconds = 28.510 FPS
138 frames in 5.0 seconds = 27.505 FPS
139 frames in 5.0 seconds = 27.585 FPS
146 frames in 5.0 seconds = 29.117 FPS

with QXL driver (1920x1080) tearing
without XPresent
[rave@f26 ~]$ glxgears -fullscreen
92 frames in 5.0 seconds = 18.366 FPS
92 frames in 5.0 seconds = 18.228 FPS
96 frames in 5.0 seconds = 19.175 FPS
97 frames in 5.0 seconds = 19.249 FPS
95 frames in 5.0 seconds = 18.850 FPS
97 frames in 5.0 seconds = 19.302 FPS
94 frames in 5.0 seconds = 18.674 FPS
95 frames in 5.0 seconds = 18.985 FPS
99 frames in 5.0 seconds = 19.767 FPS

with QXL driver (1920x1080) tearing
with XPresent
[rave@f26 ~]$ glxgears -fullscreen
93 frames in 5.0 seconds = 18.579 FPS
94 frames in 5.0 seconds = 18.670 FPS
88 frames in 5.1 seconds = 17.365 FPS
96 frames in 5.0 seconds = 19.079 FPS
95 frames in 5.0 seconds = 18.856 FPS
93 frames in 5.0 seconds = 18.582 FPS
94 frames in 5.0 seconds = 18.698 FPS
94 frames in 5.0 seconds = 18.708 FPS

It seems there is no tearing with XPresents and using new virtio driver with 3D acceleration and performance is definitely improved.
But i am not sure as glxgears doesn't run very smooth in Vm.
Not the best tool for testing for me.

On my main box with nvidia-340xx driver i have no problems to run this compiled version of marco, but as expected i see no improvement.
How can i see if XPresents is running for verifying?
More tests with intel driver on my notebook tomorrow.

@raveit65

This comment has been minimized.

Member

raveit65 commented Oct 25, 2017

My results in VM with lower resolution. (1024x768)

with virtio (3D acceleration) driver (1024x768) no tearing!
without XPresent
[rave@f26 ~]$ glxgears -fullscreen
336 frames in 5.0 seconds = 67.174 FPS
354 frames in 5.0 seconds = 70.788 FPS
361 frames in 5.0 seconds = 72.033 FPS
361 frames in 5.0 seconds = 71.955 FPS
353 frames in 5.0 seconds = 70.491 FPS
366 frames in 5.0 seconds = 73.071 FPS
353 frames in 5.0 seconds = 70.537 FPS
363 frames in 5.0 seconds = 72.574 FPS
356 frames in 5.0 seconds = 71.089 FPS

with virtio (3D acceleration) driver (1024x768) no tearing!.
with XPresent
[rave@f26 ~]$ glxgears -fullscreen
464 frames in 5.0 seconds = 92.699 FPS
478 frames in 5.0 seconds = 95.384 FPS
484 frames in 5.0 seconds = 96.721 FPS
457 frames in 5.0 seconds = 91.373 FPS
465 frames in 5.0 seconds = 92.927 FPS
461 frames in 5.0 seconds = 92.063 FPS
463 frames in 5.0 seconds = 92.519 FPS
470 frames in 5.0 seconds = 93.937 FPS
461 frames in 5.0 seconds = 92.006 FPS
460 frames in 5.0 seconds = 91.968 FPS
458 frames in 5.0 seconds = 91.544 FPS
462 frames in 5.0 seconds = 92.200 FPS

with QXL driver (1024x768) no tearing!
without XPresent
[rave@f26 ~]$ glxgears -fullscreen
258 frames in 5.0 seconds = 51.486 FPS
260 frames in 5.0 seconds = 51.818 FPS
256 frames in 5.0 seconds = 51.117 FPS
245 frames in 5.0 seconds = 48.825 FPS
256 frames in 5.0 seconds = 51.079 FPS
257 frames in 5.0 seconds = 51.374 FPS
259 frames in 5.0 seconds = 51.652 FPS
263 frames in 5.0 seconds = 52.598 FPS
263 frames in 5.0 seconds = 52.486 FPS

with QXL driver (1024x768) no tearing!
with XPresent
[rave@f26 ~]$ glxgears -fullscreen
409 frames in 5.0 seconds = 81.760 FPS
417 frames in 5.0 seconds = 83.166 FPS
430 frames in 5.0 seconds = 85.956 FPS
415 frames in 5.0 seconds = 82.977 FPS
422 frames in 5.0 seconds = 84.118 FPS
385 frames in 5.0 seconds = 76.969 FPS
421 frames in 5.0 seconds = 84.009 FPS
425 frames in 5.0 seconds = 84.883 FPS
413 frames in 5.0 seconds = 82.538 FPS
416 frames in 5.0 seconds = 83.159 FPS
379 frames in 5.0 seconds = 75.761 FPS
378 frames in 5.0 seconds = 75.451 FPS
406 frames in 5.0 seconds = 81.185 FPS

To summarize i don't see see any tearing with/without XPresents,
and performance is drammaticly increased with using XPresents, which is good :-)

@raveit65

This comment has been minimized.

Member

raveit65 commented Oct 25, 2017

Now with intel i915 driver.

without XPresent tearing
[rave@satellite ~]$ glxgears -fullscreen
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
304 frames in 5.0 seconds = 60.705 FPS
300 frames in 5.0 seconds = 59.976 FPS
300 frames in 5.0 seconds = 59.976 FPS
300 frames in 5.0 seconds = 59.976 FPS
300 frames in 5.0 seconds = 59.976 FPS
300 frames in 5.0 seconds = 59.976 FPS
300 frames in 5.0 seconds = 59.976 FPS

with XPresent tearing seems to be gone partially!
[rave@satellite ~]$ glxgears -fullscreen
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
304 frames in 5.0 seconds = 60.636 FPS
300 frames in 5.0 seconds = 59.977 FPS
300 frames in 5.0 seconds = 59.975 FPS
300 frames in 5.0 seconds = 59.977 FPS
300 frames in 5.0 seconds = 59.976 FPS
300 frames in 5.0 seconds = 59.978 FPS
300 frames in 5.0 seconds = 59.975 FPS

[rave@satellite ~]$ lsmod | grep i915
i915 1794048 8
i2c_algo_bit 16384 1 i915
drm_kms_helper 159744 1 i915
drm 352256 4 i915,drm_kms_helper
video 40960 2 msi_wmi,i915

This results are a bit disappointing for me as i see graphical issues with glxgears and no performance improvement like in VMs.
Good that i use proprietary nvidia driver on my main box without tearing with regular usage, ie watching videos :-)

@flexiondotorg

This comment has been minimized.

Member

flexiondotorg commented Oct 25, 2017

@raveit65 On actual hardware the fps won't exceed your monitor refresh (vsync) frequency, which is typically 60hz.

@raveit65

This comment has been minimized.

Member

raveit65 commented Oct 25, 2017

On actual hardware the fps won't exceed your monitor refresh (vsync) frequency, which is typically 60hz.

Got it, but i see tearing with glxgears with intel i915 and XPresent.

With nouveau driver i can confirm that the tearing is gone on my main box.
So, time for a code review as most of it i do not really understand :-)
@monsta ^^^^^

@raveit65

I see improvements with using nouveau drivers and drivers for qemu-kvm VMs

@raveit65

This comment has been minimized.

Member

raveit65 commented Oct 25, 2017

For ppls like me who don't know what DRI3 or XPresent is
https://lwn.net/Articles/569701/

@monsta

This comment has been minimized.

Member

monsta commented Oct 25, 2017

Well, marco doesn't crash after start now with no XPresent compiled in, which is good. I'll check how it runs with XPresent, but I only have proprietary nvidia drivers, so I expect no changes.

@lukefromdc

I didn't see any problems caused by this on AMD Radeon evergreen (r600) hardware. I don't have anything newer than that so can't test the AMDgpu driver. On my Xorg.0.log, I see DRI3 enabled so presumably it was used.

@monsta

This comment has been minimized.

Member

monsta commented Oct 26, 2017

Stupid dependencies bugs...
In Debian it's possible to have libxpresent-dev package installed but don't have x11proto-present-dev at the same time. There should be a runtime dependency, but it's not there. The problem is that /usr/include/X11/extensions/Xpresent.h has this:

#include <X11/extensions/presenttokens.h>

If that header (from x11proto-present-dev) isn't there, the check for Xpresent.h fails as well:

checking for XPresentPixmap in -lXpresent... yes
checking for X11/extensions/Xpresent.h... no

Took me a while to figure out that I need to install two packages instead of one. 🙂

@lukefromdc

This comment has been minimized.

Member

lukefromdc commented Oct 26, 2017

I had to rebuild and recheck as I also did not have libxpresent installed. On the rebuild, the configuration included xpresent yes, again it built and ran fine, again no visible difference on this rather powerful machine.

@monsta

This comment has been minimized.

Member

monsta commented Oct 27, 2017

So marco works as before for me, and there are no changes with nvidia proprietary drivers, as predicted.
But can anything be done for these drivers?

@vkareh

This comment has been minimized.

Member

vkareh commented Oct 27, 2017

@monsta - not really for nvidia proprietary drivers, no. As far as I know, you can enable double buffering along with forcing a full composition pipeline in your xorg.conf - that effectively allows it to behave similarly to what XPresent does (as to whether that solves tearing or not is a highly debated question).

The nvidia drivers, of course, have support for all this internally, they just don't support the APIs that allow X to leverage these features in code.

@raveit65

This comment has been minimized.

Member

raveit65 commented Oct 27, 2017

But can anything be done for these drivers?

nvidia proprietary drivers don't support DRI3.
No DRI3 --> no XPresent

@flexiondotorg

This comment has been minimized.

Member

flexiondotorg commented Oct 29, 2017

I've built Xpresent patched versions of marco 1.18.1-4 for Ubuntu MATE 17.10 and 18.04 in the following PPA:

Intel

Tested on Intel I see no regressions. By default I still see screen tearing using glxgears -fullscreen but screen tearing was removed by creating /usr/share/X11/xorg.conf.d/20-intel.conf with the following contents:

Section "Device"
    Identifier "Intel Graphics"
    Driver "intel"
    Option "DRI" "3"
EndSection

nvidia

Using the nvidia proprietary drivers I see no regressions and, as others have stated, I see no improvement either.

Conclusion

Look good to merge to me 😄

@flexiondotorg

Tested on Intel and nvidia. No regressions. When DRI3 is enabled screen tearing is gone.

@raveit65

This comment has been minimized.

Member

raveit65 commented Nov 10, 2017

merged
ac93ac0
0400a53
31a7351
9e4ecf3
b5d6dd0
99e0041

Thank you for that work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment