VSync for xrender backend

[yshui]

I want vsync for the xrender. And I want it to actually work, and doesn't involve OpenGL. The only options that meet the criteria seems to be the Present extension.

However, based on my experiment, this doesn't work under the NVIDIA driver. The Present extension is supported, but there is still tearing when using the extension.

This issue will be used to tracking my progress on investigating this.

Edit: The new backends now have working vsync for some drivers. See https://github.com/yshui/compton/wiki/Vsync-Situation

[aufkrawall]

I'd love to give it a try with mesa, but it doesn't compile atm.

[yshui]

I got vsync to work on intel driver with this method. Also I asked about this on NVIDIA's forum.

Still waiting for reply.

[yshui]

Using Present with NVIDIA also seems to drastically increase the CPU usage of X server.

[yshui]

NVIDIA users might have to use the GLX backend, I guess.

[9ary]

Using the Present extension directly could have some nice benefits for the OpenGL backend as well, as it could enable implementation of custom vsync modes, in particular one similar to Vulkan's mailbox mode which should help minimize latency and improve performance (but could increase the number of rendered frames per presented frame).
See this (I've tried the listed OML method but couldn't get it working on my Intel-based laptop).

[yshui]

@Streetwalrus When we use OpenGL, we try using it idiomatically, instead of poking into the internals and doing weird stuff.

If we want Vulkan, we can use Vulkan.

[9ary]

I can understand sticking to idioms, but the interface for this is standardized, so it's not really "poking around with the internals and doing weird stuff". I'll let you be the judge on this though.

[yshui]

@Streetwalrus How do you use the Present extension directly with OpenGL? I know Mesa is already using Present for buffer swapping if you have DRI3, if we start doing Present ourselves, that will definitely cause some conflicts.

[9ary]

It won't be a problem as long as you don't call glxSwapBuffers. Getting the right pixmap is the tricky bit and will require some digging, but I think it should be possible.
Edit: nevermind, I think figuring out why OML doesn't work would be easier. I was forgetting about the limitations of GLX. Both EGL and Vulkan should allow exporting the framebuffer through side channels (and the latter offers the swap modes I'm after), but GLX would probably require some hacks.

[clapbr]

Tested the latest xrender backend, runs reeeeally slow on my AMD RX580+Ryzen 2600 (6c/12t). xorg process goes to 100% cpu until I kill compton.

[aufkrawall]

Is there something else that needs to be done to activate new xrender vsync after compiling from #next?

[yshui]

@aufkrawall The new backend is not enabled in next, they are in split-backends. But for vsync, you need to use the tmp branch (which, as you can tell by the name, is temporary).

[aufkrawall]

Thanks. It just freezes for me and I have to abort via Ctrl + c:
https://pastebin.com/xcxC78x6

[yshui]

@aufkrawall yeah, I'm not surprised. It's really not ready for anything yet.

But if you are willing to investigate, please go ahead :)

[ChrisLahaye]

NVIDIA users might have to use the GLX backend, I guess.

Great work you are doing. Can you maybe do a small write up and what the differences are between the backends, and which should be preferred under which circumstances?

[yshui]

@ChrisLahaye Great idea. I think now is probably not the right time, since some big changes to the backends are coming up. But I will keep that in mind.

[yshui]

@aufkrawall If you have time, can you try the tmp branch again? You should start it with compton --config=/dev/null --backend=xrender --vsync=opengl (vsync can be anything other than none)

[aufkrawall]

It doesn't crash anymore and vsync seems to be fully functional. Input latency seems to be the same as with GLX swc + glfinish. Also CPU usage looks normal.
However, windows which don't have focus are constantly flickering for me, they are turning black for some moments. This is on KDE Plasma. This is increasing when switching between different windows as active ones.

[yshui]

@aufkrawall Thanks for the feedback!

[aufkrawall]

Gladly. Good news is it also doesn't show the stutter problem with amdgpu.dc=1 + radv + mpv.
It also solves a minor stutter when stopping autoscroll in Firefox (which I haven't mentioned yet, as afair even Gnome-Mutter shows this behavior).

[yshui]

@aufkrawall I suspect those stutters are OpenGL specific problems, so they don't show up in xrender.

[aufkrawall]

The Firefox autoscroll stutter (it really happens only once when stopping it, not in between) also happens with xrender + TearFree. And the mpv stutter doesn't happen with glx + TearFree (instead of Compton's own vsync). Makes me curious to see what will happen with Compton's future GLX vsync rework. :)

[aufkrawall]

Congrats to your new experimental xrender backend and vsync, they achieve perfect vsync with minimal latency for me on a RX 580 (same as Gnome-Mutter or Windows DWM). What a great success!
I suppose it's still WIP, but some feedback regardless :) :
-Fading looks rather choppy and turning fading off can lead to weird "ghost" behavior when closing windows, they flicker a few times before finally disappearing.
-It's rather crashy when starting fullscreen games (also without auto unredirect).
-It doesn't prevent tearing inside Vulkan windows when the applications don't have vsync activated by themselves, e.g. vkquake.
-Is there already an option to use/configure buffer-age with it?

Really looking forward to it leaving experimental state.

Btw: When starting Compton with "-experimental-backends" instead of "--experimental-backends", somehow my KDE Plasma window decorations disappear. It probably should simply abort when using just one hyphen?

[yshui]

Fading looks rather choppy and turning fading off can lead to weird "ghost" behavior

Do you have a screenshot/recording of that?

It's rather crashy when starting fullscreen games

This is known, I understand why it happens, but it probably won't be fixed before v7.

It doesn't prevent tearing inside Vulkan windows

Weird. Does this happen with the old backends?

Is there already an option to use/configure buffer-age with it?

It always use buffer-age.

When starting Compton with "-experimental-backends" instead of "--experimental-backends",

Hmm the single hyphen version should be simply ignored, not sure what happened here.

Also, thanks for testing the new backends :)

[aufkrawall]

Do you have a screenshot/recording of that?

Not sure if I can record the "ghost" behavior yet, as it seemed to happen rather erratically and it's too unstable for daily usage.
But the choppy fading is easy to spot with my settings, which are:
fading = true;
fade-delta = 4;
fade-in-step = 0.03;
fade-out-step = 0.03;

The new GLX backend doesn't show this behavior, only new xrender.

Weird. Does this happen with the old backends?

It [tearing inside Vulkan windows with application vsync disabled] happens only with the new xrender backend, but not new GLX or old GLX backends.

The new GLX backend also shows some stuttering in Firefox, e.g. when scrolling with mouse wheel or at vsynctester.com.
It also shows the same input latancy as the old GLX backend with --vsync = opengl-swc, which is quite high.

[yshui]

Fading looks rather choppy

Maybe that's just because of frame drop.

[aufkrawall]

Fading looks rather choppy

Maybe that's just because of frame drop.

Now that you say it: It really looks like that.

[aufkrawall]

Hm, there seems to be a connection to vsync regarding my browser input stutter issue. When I run vblank_mode=0 compton, it doesn't occur. Vsync btw. is always enabled, despite of having --vsync not specified or set it to false.

Edit: The issue also occurs with modesetting driver, but to a much lesser extent. So I guess the problem really lies in the new GLX backend and not the Xorg drivers.

However, the window snap frame drop issue is not related to it.

[clapbr]

RX580 user here, I also have browser stuttering (chromium and ff) with glx backends. The new xrender backend performs fine in browsers but both are not quite stable yet for my setup and segfaults frequently (can´t reproduce reliably for a report unfortunately).

I always end up going back to 5.1 and vblank_mode=0 --vsync=opengl --backend=glx - as Bobby Fischer used to say, best by test.

Kinda annoying that amd drivers can't figure a good vsync solution after all this time and hacks like vsync=opengl/drm works better than what was supposed to be the right way. Seems they keep trying to change behavior every other month, but end up breaking it again and there is always something really annoying still present like random frame drops, stutters when you do specific stuff, mpv desyncing, browser jerkiness etc.
Today after lots of hours trying to find the culprit for consistent 1 frame drops every 10-15 seconds it was redshift. Checked bugzilla and it seems they've still haven't figured async fb changes, guess that's also what causes drops when moving the mouse across windows and possibly other issues we frequently see.

I can feel yshui's pain having to mantain something that relies on broken drivers.

Sorry for the big rant but I felt it needed to be said.

[aufkrawall]

@clapbr Could you compile git-next with debug symbols and provide the crash dump + binary?
Afaik Intel suffers the same by the current atomic modesetting limitations, AMD didn't invent that framework. ;)

[tmpm697]

I use the same config on PC and laptop. Laptop with ver 5.1 caused tearing (I used both on-board hd630 & Nvidia MX150 - matebook x pro 2018 via bbswitch) then I tried to adapt new compatible config with ver 6.2 on lap, I observed no tearing but wallpaper flick when startx and noticeable lag on lap compare to ver 5.1. More ram, lag on prompt --> switch back to ver5.1 even tearing.

on PC (only intel hd 620) ver 5.1 work perfectly, no tearing, no lag.

[aufkrawall]

One week of using new Xrender backend after commit 4205ee5 , and there are zero issues to report. :)

[clapbr]

One week of using new Xrender backend after commit 4205ee5 , and there are zero issues to report. :)

Also not having segfaults anymore on latest, also using xrender and no issues yet.

[tmpm697]

@aufkrawall @clapbr can you guys share compton.conf and the command you invoke it?

[Ropid]

@tmpm697:

Here's my config, I'm also using the new xrender and it seems to run great:

http://ix.io/1HUD

To make this work like intended, it's important to start compton with the parameter that enables the new backends, like so:

compton --experimental-backends

[tmpm697]

@Ropid : Thanks, I finally be able to make it free tearing with arch/nvidia gpu card use new glx backends.

I noticed that new xrender backend still cause tearing when playing games.

[yshui]

@tmpm697 Yes, the vsync in new xrender backend doesn't work with nvidia cards. It's a driver problem unfortunately. (See here)

[aufkrawall]

@yshui Were the tracelogs helpful which I provided for my problems with new GLX backend? :)

[yshui]

@aufkrawall These kind of problems are quite difficult to track down :/

[tmpm697]

Do you guys see some difficulties when start Xorg with new 6.2 compton? From black screen to appearance of wallpaper, there's strong flick between the transformation.

[aufkrawall]

@yshui One more crash issue which might be related to unredir. Happens when a weird resolution switch with Wine Vulkan apps is happening:
compton.zip

[Ropid]

I need some help here! I don't know what to do next to research the following problem:

I started having tearing at the top of the screen with xrender + present. It seems to be happening with both the normal packages in Arch and the development versions of all Mesa and Xorg and amdgpu stuff.

I don't know when exactly this started because the tearing is happening very close to the top of the screen, about 30 pixels away from the edge. I might not have noticed this happening for a very long time because of a panel covering most of those 30 pixels. Maybe this was always there and I never noticed?

Looking around, I found this bug report here:

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

I then tried the git version of xf86-video-amdgpu but it doesn't help with this tearing I see here.

I also tried different kernels and I get the tearing with 4.19.x, 5.0.x, 5.1.x.

[aufkrawall]

@Ropid Are you certain that amdgpu DDX is actually used (e.g. forgot that modesetting driver was set up in xorg.conf)? No weird errors in xorg.log?

[Ropid]

@aufkrawall: Yeah, I'm using amdgpu and I'm not getting error messages in the Xorg file while using it. But you mentioning modesetting made me try that X driver instead of amdgpu. When using modesetting I do get interesting error messages that look related to that bug report:

[  8102.599] (EE) modeset(0): Failed to get GBM bo for flip to new front.
[  8102.599] (EE) modeset(0): present flip failed
[  8102.608] (EE) modeset(0): Failed to get GBM bo for flip to new front.
[  8102.608] (EE) modeset(0): present flip failed

I'm now trying to find a PKGBUILD for the git version of xorg-server to check out the patched modesetting driver that was mentioned in that bug report.

EDIT:

I managed to build the git version of xorg-server. The modesetting driver that comes with it is also showing tearing. Compared to the modesetting driver that comes with stable xorg-server, the log file error messages are gone but not the tearing itself. The version I'm trying is this here:

$ pacman -Qi xorg-server-git
Name            : xorg-server-git
Version         : 1.20.0.330.r16964.g2aec5c3c8-1
...

The way I'm testing stuff is by dragging a browser window with www.vsynctester.com half outside of the screen with Alt+click. I move it so that the flashing "VSYNC" text is at the edge of the screen. I can then see part of this "VSYNC" text flash red or cyan.

[yshui]

@Ropid I tried but cannot reproduce this problem.

I won't be surprised if non-git xf86-video-amdgpu, or non-git modesetting have this problem (because of the bugs). But I don't understand why the git versions have tearing as well.

Can you tell me more about your setup, like do you use multiple monitors, etc.?

Edit: Wait a sec, the modesetting fix hasn't been merged yet.

[aufkrawall]

Yeah, this MR based on @yshui 's original patch should be applied:
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/193

Still it shouldn't tear with amdgpu-git either. Definitely not the case for me.

[Ropid]

@yshui:

I'm using a single 60Hz 1920x1200 monitor. The card is an AMD RX480. Window manager is xfwm4.

I tried MATE's "marco" to compare. It also uses xrender and Present and it has that same tearing at the top of the screen so it's not a problem in compton. It seems to be something general about Present here for me.

The experimental glx backend of compton doesn't have a tearing problem while it seems to run with the exact same super great latency as what xrender + present manages to do.

[aufkrawall]

@yshui The stutter of new GLX backend when snapping windows to the screen borders inside a Plasma session is gone. :)
However, the keyboard (and also mouse) input stutter issue still persists (more distinct with xf86-video-amdgpu, but to a much lesser extent also there with modesetting driver).
It seems input somehow makes it block or wait.

Edit: Moving the mouse cursor doesn't trigger it, but repeatedly clicking does (doesn't matter what is clicked, can also be the desktop background).

Edit 2: There is still a minor jump noticeable of the moving window when snapping to borders, but everything else seems to continue running smoothly now. That minor jumps is not there with xrender or old GLX though.

Edit 3: For whatever reasons, the "input stutter problem" doesn't seem to affect rendering completely, but only single windows like browser. For instance, playback of mpv seems to be totally unaffected.

[yshui]

@aufkrawall

For whatever reasons, the "input stutter problem" doesn't seem to affect rendering completely, but only single windows like browser. For instance, playback of mpv seems to be totally unaffected.

Can you elaborate? Do you have mpv and browser side by side, and input into the browser only cause the browser to stutter? And this doesn't happen when compton is not running?

If so, that's super weird.       ^{and probably not a compton problem}

[aufkrawall]

@yshui

@aufkrawall

For whatever reasons, the "input stutter problem" doesn't seem to affect rendering completely, but only single windows like browser. For instance, playback of mpv seems to be totally unaffected.

Can you elaborate? Do you have mpv and browser side by side, and input into the browser only cause the browser to stutter? And this doesn't happen when compton is not running?

If so, that's super weird. and probably not a compton problem

It's like you described, but the input doesn't have to be inside the browser window. When the Chromium window is unfocused and I keep buttons pressed (e.g. to switch selected desktop icons), it is enough to cause vsynctester.com to stutter. The same goes for mouse click input.
This happens only with new GLX backend and with vsync enabled at the same time.
Playing a juddertest video in mpv is definitely unaffected by this.

[aufkrawall]

I dumped Windows on my Gemini Lake notebook (hopefully for good) and on this very weak (you could choose less polite words) SoC, new xrender backend + vsync performs absolutely fine as well, by far less performance impact on the webbrowser than GLX backends.

[yshui]

@aufkrawall Probably the browser is missing the vblank window because of the input? Since mpv is unaffected I am inclined to think this is not a compton problem.

[aufkrawall]

@yshui Perhaps the new xrender backend can be used by default instead of the old one with the next version? Can only judge my own situation, but it's just perfect here with both AMD & Intel (driver flaws not considered).

[yshui]

@aufkrawall I want to get more feedback on the --experimental-backends first before doing anything.

[yshui]

closing as done