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, weird. Could it be the latest changes for the new GXL backend also improved performance for new xrender backend? At least my fading performance issue is gone after recompile.

Regarding the tearing inside Vulkan windows with new xrender: I can't reproduce it with latest 5.0 kernel, so perhaps it's a regression of amdgpu.dc in their latest drm-next-5.2-wip kernel which I was using before.

Edit: Did a little benchmark with a game (limited by GPU, not CPU): No compositor: ~111.2fps Compton new Xrender + vsync: ~108.3fps Costs just ~2.6%, which is a great result and supposedly better than Windows DWM. :) (CPU performance doesn't seem to be relevant anyway.)

[aufkrawall]

Btw. also very cool that --use-damage also works with the old xrender backend. Polaris has some highly oversensitive clock adjustment on Linux and reusing image parts via buffer-age greatly helps keeping clocks low. It also still works well together with TearFree for vsync.

Though vsync of new xrender backend is still the better deal, as it offers lower CPU usage when moving windows and is less vulnerable to stuttering with high background GPU usage (e.g. game in windowed/borderless mode behind browser window). Would it be presumptuous to bid you to fix the crash problem before further attending to the new GXL backend etc.? I'd be very grateful. :heart:

[aufkrawall]

Ok, noticed one minor performance issue: Resizing of certain Qt windows is slowed down with new xrender + vsync, e.g. KWrite or Plasma's system settings window, it gets really stuttery. Other Qt windows such as dolphin or GTK windows seem to be unaffected.

[yshui]

@aufkrawall Yes, I noticed that too. Resizing is severely slowed down. Thanks for confirming.

[yshui]

@aufkrawall Can you try dev?

It works on my intel machine but not on my NVIDIA machine. I suspect there're some NVIDIA shenanigans going on again.

[aufkrawall]

I can confirm your Intel findings with AMD, resizing of the mentioned windows now looks totally normal with dev branch & new xrender backend.

Regarding the crashes: Oddly, especially starting Pamac is prone to trigger them. Thus I've tried out starting various programs a few times, with emphasis on Pamac. Looking good so far with dev branch. Of course still a bit early to judge.

Edit: Still crashy. :)

[aufkrawall]

With the more recent commits, the crashes have mostly disappeared, but not entirely. The last time it did when starting vkquake. I tried to find a way to reproduce, but couldn't. It's gotten very usable though, maybe crashes once every two days, and no other undesired side effects to report.

[yshui]

@aufkrawall Do you have the log? I also recommend building with -Dsanitize=true, so you get a nice stack trace when it crashes

[aufkrawall]

I''ll do that. Do you want me to run Compton with --log-level=trace? Would be nice if it logged to disk so that the terminal window wasn't opened all the time.

[yshui]

@aufkrawall It does :) --log-file=file

[aufkrawall]

Thanks! I'll post the files if it crashes again. The stack trace should be in systemd's coredump folder?

[yshui]

@aufkrawall If you are using systemd, do coredumpctl debug, and run bt in gdb.

If you do -Dsanitize=true, the stack trace will be printed on terminal.

If you want a coredump, don't enable sanitize

[aufkrawall]

Could get it right to crashing this time when running vkquake, switching from windowed to fullscreen and then minimizing it.

I just got the suspicion that the following might not be very helpful, as I've just recalled that Arch makepkg by default strips out debug symbols:

gdb.log

So I guess I'd have to rerun this with debug symbols included.

At least there is the debug log: compton.log

[yshui]

@aufkrawall looks like dbus-send happens to crash at the same time (?) and the gdb.log you got is from dbus-send.

Can you do coredumpctl debug compton? You don't need to try crashing compton again.

[aufkrawall]

That returns

/var/lib/systemd/coredump/core.compton.1000.3b84fe6fa70f4684beb6e02a9723aa86.815.1553006421000000.lz4 (inaccessible)

Well, the file doesn't exist. :(

However, I once again could make it crash instantly by simply starting vkquake in fullscreen mode and then minimizing it.

[yshui]

@aufkrawall Have you tried building with -Dsanitize=true and run compton from terminal?

[aufkrawall]

I'll try that next.

Just in case: I compiled with debug symbols and without -Dsanitize=true. This produced this core dump:

core.compton.1000.07128ed24c8b438aa5d6b7630707cc64.830.1553090852000000.zip

[aufkrawall]

@aufkrawall Have you tried building with -Dsanitize=true and run compton from terminal?

Here we go:

compton --experimental-backends [ 20.03.2019 15:18:00.687 _win_bind_image ERROR ] Failed to get named pixmap [ 20.03.2019 15:18:13.350 _win_bind_image ERROR ] Failed to get named pixmap [ 20.03.2019 15:18:13.351 _win_bind_image ERROR ] Failed to get named pixmap ../src/backend/xrender.c:92:15: runtime error: member access within null pointer of type 'struct _xrender_image_data' AddressSanitizer:DEADLYSIGNAL

==7147==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000028 (pc 0x563d0b2609e5 bp 0x7fff7dc46e40 sp 0x7fff7dc46d90 T0) ==7147==The signal is caused by a READ memory access. ==7147==Hint: address points to the zero page.

0 0x563d0b2609e4 in compose ../src/backend/xrender.c:92

1 0x563d0b26a652 in paint_all_new ../src/backend/backend.c:138

2 0x563d0b1c6f0b in _draw_callback ../src/compton.c:1462

3 0x563d0b1cba94 in draw_callback ../src/compton.c:1484

4 0x7f8d7ced4992 in ev_invoke_pending (/usr/lib/libev.so.4+0x4992)

5 0x7f8d7ced82dc in ev_run (/usr/lib/libev.so.4+0x82dc)

6 0x563d0b1b8577 in session_run ../src/compton.c:2308

7 0x563d0b1b8577 in main ../src/compton.c:2397

8 0x7f8d7b629222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)

9 0x563d0b1bacdd in _start (/usr/bin/compton+0x110cdd)

AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV ../src/backend/xrender.c:92 in compose ==7147==ABORTING

[aufkrawall]

@aufkrawall Can you also send me the compton binary you built?

Sure.

comptonbinary.zip

[yshui]

Hmm, this shouldn't happen...

Thanks, I will investigate

[clapbr]

Sorry for the thread hijack but I didn't feel like opening a new issue for a related question. I'm still using old compton because vsync=opengl and vsync=drm are the ones that had nearly 0 input lag for me, are they ever coming back? I had no problems with it (I know some people had top screen tearing)

[yshui]

@clapbr They are not coming back. And I will try to reduce the input lag.

BTW, how does the new xrender backend with vsync work for you?

[clapbr]

@clapbr They are not coming back. And I will try to reduce the input lag.

BTW, how does the new xrender backend with vsync work for you?

Works well with low cpu usage but slows down to a crawl under heavy load. I'm almost always compiling something and with the old backend I don't feel a thing. RX580 with latest drivers