Poor performance when vsync is enabled

[9ary]

Platform

Arch Linux

GPU, drivers, and screen setup

Radeon RX580, amdgpu

Environment

i3-git

Compton version

Latest -git (v3-rc2-3-ga47f112 as of this writing)

Compton configuration:

backend = "glx"
paint-on-overlay = true
unredir-if-possible = true
glx-no-stencil = true
glx-no-rebind-pixmap = true
glx-swap-method = "copy"

opacity-rule = [
    "0:_NET_WM_STATE@:32a *= '_NET_WM_STATE_HIDDEN'"
];

Testing

The following vsync modes were tested, with GALLIUM_HUD=fps to have real numbers to compare:

• opengl-swc/opengl-mswc: massive stutter when dragging windows even though the HUD reads 60 fps. These are enabled by default with mesa and libdrm, so the rest requires vblank_mode=0 in the environment to prevent that from interfering.
• No vsync at all: nearly 1000 fps when dragging windows, perfectly smooth but obviously tears all over the screen.
• opengl or drm: smooth, (almost) no tearing, slight dips when switching workspaces.
• opengl-oml: fails to vsync.

[9ary]

Edit: Btw.: Why is there vsync enabled with mesa drivers, even with vsync = none? I don't think it should be normal that Compton has to be started with vblank_mode=0 in order to actually disable vsync.

This is mesa's fault, it enables vsync by default unless you set vblank_mode in which case it ignores the application's preference. The proper fix for this would be to explicitly disable vsync on startup (same as swc/mswc but you set the swap interval to 0).

[aufkrawall]

Ok, but why is it not enabled by default in games? I don't think they all take that particular mesa behavior into account.

[9ary]

Games probably do their own thing, you would have to trace execution to see what's going on. Firefox also seems like it's disabling vsync (at least youtube videos show substantial tearing without a compositor or tearfree).

[aufkrawall]

Is that in fullscreen mode? Xorg windows can't be free of tearing without pageflipping, which is enabled either by TearFree, a compositor or a fullscreen window.

[9ary]

Both with and without full screen. Under compton, you need to exclude Firefox from or disable unredir-if-possible.

[yshui]

@Streetwalrus Interestingly, the document here says vblank_mode=1 defaults to 0 swap interval.

Edit: Ah, I see. vblank_mode is set to 2 by default. I guess we should explicitly set swap interval to 0 for vsync = none.

[9ary]

Yep, that's pretty much what's happening.

[9ary]

Firefox also seems like it's disabling vsync (at least youtube videos show substantial tearing without a compositor or tearfree).

Nevermind that, Firefox doesn't seem to use opengl to paint the main window unless you're using webrender (which sadly has a breaking bug with idle repaints at the moment).

[aufkrawall]

@Streetwalrus Have you set layers.acceleration.force-enabled=true? Now that you say it: I always wondered why the FF window remained black after some time not touching it (using WebRender). But I can live with that, as moving the mouse usually makes the window's content visible again.

[yshui]

@Streetwalrus Would you like to make a pull request for explicitly setting swap interval?

[9ary]

@Streetwalrus Have you set layers.acceleration.force-enabled=true?

Looks like that does enable opengl for the main window and fixes tearing, good to know. Last time I checked it was enabled by default, but that might have been webrender forcing it on.

Now that you say it: I always wondered why the FF window remained black after some time not touching it (using WebRender). But I can live with that, as moving the mouse usually makes the window's content visible again.

It's pretty annoying for me, especially because I use keynav which leaves grid trails behind in this case. I've opened a bug for that here.

@Streetwalrus Would you like to make a pull request for explicitly setting swap interval?

I can take a look. I think we should also consider deprecating/removing the opengl-mswc method since it does pretty much the same thing as swc, but with a less standard extension (GLX_SGI_swap_control vs GLX_MESA_swap_control).

[yshui]

@Streetwalrus If you are sure that everything that supports GLX_MESA_swap_control also supports GLX_SGI_swap_control, then I'm fine with removing mswc.

[9ary]

I know for certain that mesa itself supports both, I don't think anything else does.

[yshui]

@Streetwalrus Good ahead then. But don't remove the opengl-mswc option, just make it do the same thing as opengl-swc

[9ary]

Yeah that's the plan.

[aufkrawall]

Maybe also print a message when used that mswc is considered obsolete? :)

[aufkrawall]

Wouldn't it be a good idea to automatically use --vsync-use-glfinish when GLX_MESA_swap_control is used? That way latency of vsync = opengl-swc could be reduced for mesa users while not affecting Nvidia users badly.

[9ary]

I think it'd be better to fix the problem at its root instead. glFinish shouldn't be needed with double buffering. Not even glFlush. I can't see a difference in my minimal test, it could be another cursor-related issue.

[aufkrawall]

I'm absolutely certain that the distance between cursor and moving window is smaller with it, so imho it's a viable workaround until we got something better.

[9ary]

workaround

And that's exactly why I think it shouldn't be enabled by default. :) I can see the difference with compton itself, but I can also see some awful jitter with it (with DC enabled), so it's not completely harmless.

[aufkrawall]

I can't see any jitter with AMD's 4.21-wip kernel & DC, where exactly do you experience it? Xorg hardware cursor is basically broken in DC before what will be that kernel version, so it wouldn't make sense to decide on basis of older kernels.

[9ary]

4.20-rc7, with hw cursor and dc. If it's broken on this, it's likely also broken on 4.19. It'd be a very stupid idea to break the current stable release, so I would at least wait until 4.21 actually hits stable.

[aufkrawall]

What I wanted to say was that it shouldn't make any difference if --vsync-use-glfinish is used or not regarding the DC cursor issue. DC + any compositor is totally unusable here with <= 4.20, no matter the vsync setting (as long as vsync is enabled at all).

[aufkrawall]

I could pin down the stutter in mpv to the combination of Compton and radv, it doesn't stutter with amdvlk. I'll see if further Compton changes will have an effect on this, and else report it to the radv devs.

[aufkrawall]

I tried --vsync-use-glfinish with Linux 4.20 & RX 580 again, my impression is it definitely doesn't make things worse than they already are. I also gave it a try on a Gemini Lake IGP and it seemed to work nicely there as well with vsync = opengl-swc. I really don't see any objections from enabling it by default for GLX_MESA_swap_control until yshui casts some vsync magic out of his sleeves. :) It just reduces input latency without apparent drawbacks.

[aufkrawall]

The fix for the problem originally discussed is now in linux 5.0-rc1.

[9ary]

I'll try it asap, currently stuck with no monitor for my desktop.

[9ary]

Just got a new monitor so I can now confirm that compton is usable now. As far as I'm concerned, the original issue is solved, so if there are no objections I'll close it.

I can also confirm that glfinish does lower latency when dragging windows but it's still not as good as vsync=opengl or vsync=drm on that front.

[yshui]

@Streetwalrus Interesting. What is different about this monitor?

[9ary]

Oh the monitor is unrelated to the issue, I was just without one for a few days (RMA'd the old one and was waiting for the refund), so I was unable to test on my amdgpu system.

[aufkrawall]

Looks like my amdgpu.dc=1 + mpv vulkan + Compton vsync stutter issue is gone, I tried it several times with several restarts in between. I'm suspecting changes in Mesa for this pleasant change, but can't yet pin it down to it as I would have to recompile llvm-git after switching to llvm stable for mesa stable, which would be quite inconvenient. At least I tried older kernels and amdgpu DDX driver, they don't seem to be responsible for this change.

[aufkrawall]

Mystery (partially) solved: The Vulkan stutter disappeared because I switched from mpv-master to @haasn 's repository, so it apparently contains a commit improving my situation. I suppose it will land in the main repo at some point, and if not it's a starting point for further investigation.

[siyia2]

the following patch fixes compton lag in linux 4.20.x series i tested it:

https://bugs.freedesktop.org/attachment.cgi?id=142574

[yshui]

@Streetwalrus Maybe this issue can be closed?

[9ary]

Yep, I was going to but was waiting for confirmation from others.

[zkeng]

Hi and thank your for the input I got from this thread. I have a new mITX workstation with an AMD Athlon 200GE (Raven Ridge) APU with Vega 3 graphics. It is running Debian Stretch, with some necessary upgrades from stretch-backports for the Zen cpu cores and Raven Ridge graphics, and I use Openbox and Compton. I got everything working great, with no issues what so ever, except that xorg will not start if I try to pass configuration options to amdgpu driver, so I was unable to activate the TearFree option and was stuck with the choice of accepting tearing or stuttering for the graphics. Your discussion gave me some new ideas and I got perfect performance now, with no tearing or stuttering and without passing any options to amdgpu driver, by instead running compton with the following options:

compton -CcG -o 0.1 --backend glx --vsync opengl-swc --vsync-use-glfinish --glx-copy-from-front --paint-on-overlay &

[zkeng]

Maybe I should add that I am on Linux 4.19, so I got it working without benefiting from the upcoming patches mentioned in this thread. For me it was just a matter of finding the magical combination of the right compton options ;)

[aufkrawall]

Afair --glx-copy-from-front partially breaks vsync (tearing might occur only very close to the top or the bottom of the screen and thus would be hard to spot), which would explain why there are no performance issues for you with kernels <5.0.

This option is deprecated (it probably has never worked correctly) and --glx-swap-method = buffer-age should be considered the best replacement for it.

[yshui]

I don't quite understand why --glx-copy-from-front breaks vsync. It could be some synchronization issue. (Did it really break vsync though?)

But, like @aufkrawall said, it really shouldn't be used nowadays.

Also IIUC, the performance fix in 5.0 is related to updating cursor position asynchronously (meaning the cursor is not updated during vblank). So I don't understand why any of @zkeng's options could affect the performance.

[zkeng]

@aufkrawall I know about the tearing issues near the top (even though I only experienced them with 'drm' and 'opengl' options), but with the combination of options i posted I experience no tearing and no stuttering and have even tested with a tearing-detection video in both windowed and fullscreen mode. I am kind of picky with tearing because I work with graphics (building/housing architect), but don't care much for frame rates because I don't game.

[zkeng]

I have no idea about what the options really do (i mean the actual code since I am not a programer), but we run Debian at the office as well and there has always been a difference in optimal settings in our opengl-accelerated CAD application to get good performance depending on if we are using intel, nvidia, or amd graphics (we use mainly amd). Setting the GL Swap Mode to "call glx swap buffers" have always been the best option for nvidia and intel gpus. For older versions of the proprietary AMD catalyst driver setting "glx copy pixels back to front" was optimal. For the open source radeon driver setting "call glx swap buffers then call glx copy pixels back to front" is optimal and the same option is optimal with the gpus in the Bristol Ridge series of APUs using the open source amdgpu driver. For Raven Ridge APUs using the open sourxe amdgpu driver it seems like the option "call glx swap buffers" is optimal, just like it is for nvidia and intel gpus. I have no idea if this is because of differences in the hardware, or the drivers, or between different versions of the drivers, but I know for sure these are the optimal settings, because I manage our systems at work and I have also helped people in the (Brics)CAD forum with the correct settings to avoid terrible stuttering and graphics corruption when using AMD hardware.

[zkeng]

Typo: For the open source radeon driver setting "call glx swap buffers then call glx copy pixels FRONT TO BACK" is optimal.

[zkeng]

Some detailed info about my experience with the options I used: '--paint-on-overlay' makes no difference for performance and can be left out. '--vsync opengl-swc' always produces tear free rendering, but has slow performance and stuttering without the '--glx-copy-from-front' option. '--glx-copy-from-front' together with '--vsync opengl-swc' produces severe (as in unusable) screen corruption unless combined with the '--vsync-use-glfinish' option. Changing 'opengl-swc' to 'opengl' or 'drm' produces tearing at the top without the '--glx-copy-from-front' option and stuttering with the '--glx-copy-from-front' option.

[yshui]

@zkeng Which version of compton are you using? I am confident that --glx-copy-from-front stopped doing anything since v3.

[zkeng]

Sigh Debian and the habit of implementing their own version numbers for packaged binaries... apt says its version: 0.1~beta2+20150922-1 but maybe the date tells you what you need to know. It is the version packaged in the Debian Stretch repos.

Sorry if I bumped your closed topic. Didn't really mean to engage you in more talk about it. Just wanted to say thanks and that your discussion solved my last problem with Raven Ridge compatibility. And also wanted to post what worked for me in case anyone else is searching for a fix. Specially since so many Linux users have been asking questions about problems with Raven Ridge in all kinds of forums, but rarely care to post after resolving any issues, with the result that it looks like then new AMD chips are a nightmare on Linux when actually this 200GE system is working spotlessly for me after getting rid of tearing with the help of Compton.

[yshui]

No worries