Poor performance when vsync is enabled about picom

[yshui]

I am aware of the performance problem with moving windows in opengl, and am actively trying to solve it.

Although that might take a long while given the manpower we currently have or lack thereof.

[aufkrawall]

Well, if you can, you should really try "amdgpu.dc=0". Compton runs completely fine for me with this old display controller driver, and so does the hardware cursor in general.

[clapbr]

Good news, we have a fresh kernel patch for this:
https://bugs.freedesktop.org/show_bug.cgi?id=106175#c55

I am using it on my custom kernel right now and it seems to solve the issue entirely. Let's hope it get merged upstream soon.

[aufkrawall]

Ok, seems to be some very specific problem of amdgpu.dc=1, xf86-video-amdgpu + Compton + mpv video-sync=display-resample + playback in fullscreen, or in short: It doesn't stutter with Gnome-Mutter.

But I found a nice workaround: TearFree works well with amdgpu.dc=1 + the patch provided in the bugtracker ticket.
So I enable both (patched) amdgpu.dc=1 and TearFree, set Vsync=none in Compton config and start Compton with defined variable vblank_mode=0.
-> This results in elimination of tearing, lag and also stutter in mpv. I disable TearFree via hotkey for games.

[aufkrawall]

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

[yshui]

So opengl-swc does work? I will file this under performance problems.

Also, do you still get tearing with openly vsync?

[9ary]

opengl and drm vsync do work for the most part but there is a consistent tear near the top of the screen that is noticeable if you really look for it. swc/mswc give me perfect vsync but terrible performance.

[9ary]

It doesn't make sense though, like I said without vsync I'm seeing near 1000 fps figures. mswc is also working fine on my laptop (Intel graphics).
I appreciate the effort you're putting in to fix things up, I've looked into it myself and decided it'd be less trouble to write a new compositor from scratch, but I don't have the motivation to work on it.

[yshui]

I've looked into it myself and decided it'd be less trouble to write a new compositor from scratch

I agree with you on that one. That's why I'm trying very hard to refactor the code so it could be easier to contribute to this project.

[yshui]

According to @jm33-m0, this also happens on intel card. Refer to #26 for details about his hardware and configuration.

[aufkrawall]

Perhaps you are experiencing this bug?
https://bugs.freedesktop.org/show_bug.cgi?id=106175
It needs to be fixed in amdgpu kernel driver, as it's a general problem with xorg pageflipping + hardware cursor and amdgpu.dc.

As a workaround, you can set "amdgpu.dc=0" as kernel parameter, unless you have Vega or Raven Ridge GPUs that aren't supported by old legacy dc.
It should work normally with GLX backend and any vsync mode then (imho "drm" and "opengl" have lower input latency than the others).

If you can confirm that it's the bug I linked above, please let AMD know on their bugtracker. This issue exists for a very long time now.

[clapbr]

The situation on this issue for me (on a RX580) is improved a lot with the latest AMD kernel https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.21-wip and mesa-git - So even if you cant or dont want go unstable the improvements might hit stable in a few months when kernels 4.20-4.21 and mesa 18.3 release.

[aufkrawall]

I already tried drm-next-4.21-wip a few days ago and it unfortunately didn't help with my issue.

[clapbr]

I already tried drm-next-4.21-wip a few days ago and it unfortunately didn't help with my issue.

can you try:

vblank_mode=0 compton --backend glx --vsync opengl

and see if thats better? I've just tested it vs a few other options and this is the only one that made my glx backend both stutterless and tearless. I've used to use xrender with vsync=opengl because glx was a bit laggy. I suspect compton is double vsyncing if I don't specify vblank_mode=0. This doesn't solve opengl-swc and opengl-mswc modes though because vblank_mode=0 will in this case disable vsync all together.

[aufkrawall]

Thanks for your help. Yes, I tried that in the past. It looks fine at first and also has less input lag.
But: After some time I noticed that there is a very small stripe of tearing at the very top of the screen. It basically leads to the same result as turning off pageflipping in xorg config.

One other ugly workaround would be to turn off the hardware cursor. Then we can move windows without stuttering in general, but cursor will stutter when there is high system load and software cursor also has increased latency.

I think we are quite screwed until AMD can manage to fix the bug.

[yshui]

One other ugly workaround would be to turn off the hardware cursor.

This blows my mind. How is hardware cursor involved in this?

[aufkrawall]

I suppose that would need to be bisected by a kernel developer who can reproduce the issue.

The problem doesn't seem to be located in user space in any way, every fullscreen application with active hardware cursor (e.g. also some games) is affected.

[clapbr]

Thanks for your help. Yes, I tried that in the past. It looks fine at first and also has less input lag.
But: After some time I noticed that there is a very small stripe of tearing at the very top of the screen. It basically leads to the same result as turning off pageflipping in xorg config.

One other ugly workaround would be to turn off the hardware cursor. Then we can move windows without stuttering in general, but cursor will stutter when there is high system load and software cursor also has increased latency.

I think we are quite screwed until AMD can manage to fix the bug.

I think I know which small stripe you're talking about, it indeed used to happen for me after some time specially if you open/close/open some windowed videos but in this current setup it hasnt happened for me yet. I think our best option is to make AMD fix it entirely since other compositors that used to work fine are also in a bad state (kwin comes to mind, which for me is not even as tweakable to a mostly fine performance as compton is). AMD's own Tearfree option used to be good without a compositor and is also in a bad state.

One other ugly workaround would be to turn off the hardware cursor.

This blows my mind. How is hardware cursor involved in this?

In my experience hardware cursor is related to all kinds of stutter, at least indirecly since I think if you disable it you also disable gl flips. I have some games that run like shit with hardware cursor (Diablo 3 comes to mind but havent played it for ages).

Today I was testing the new Freesync patches and hardware cursor also interacted terribly with in specific games and Freesync, making games go from smooth 75fps to ~25fps only when I moved the cursor. You arent supposed to use freesync with compositors also but I tried it for the science and compton also lags with Freesync when I move the mouse. Funnily if I play the same games under same setup with keyboard and gamepad they are smooth.

[clapbr]

Comment from dev about the HW cursor issue https://bugs.freedesktop.org/show_bug.cgi?id=106446#c2

[clapbr]

Tried this xorg conf with glx and all --vsync options and it gets SIGNIFICANTLY better. at the cost of a little bit of input lag and cursor flashing in some places. HW cursor is definetely messed up somehow

Section "Device"
### Available Driver options are:-
### Values: : integer, : float, : "True"/"False",
### : "String", : " Hz/kHz/MHz",
### : "%"
### [arg]: arg optional
#Option "Accel" # []
#Option "SWcursor" # []
#Option "EnablePageFlip" # []
#Option "SubPixelOrder" # []
#Option "ZaphodHeads" #
#Option "AccelMethod" #
#Option "DRI3" # []
#Option "DRI" #
#Option "ShadowPrimary" # []
#Option "TearFree" # []
#Option "DeleteUnusedDP12Displays" # []
#Option "VariableRefresh" # []
Identifier "Card0"
Driver "amdgpu"
BusID "PCI:1:0:0"
Option "DRI" "3"
Option "SWcursor" "true"
EndSection

[aufkrawall]

This is truly great. :)

However, I just noticed another amdgpu.dc bug which introduces stuttering in mpv when at least Compton is active. partyruined

[clapbr]

This is truly great. :)

However, I just noticed another amdgpu.dc bug which introduces stuttering in mpv when at least Compton is active. partyruined

Interesting, I also had mpv stuttering today on specific videos (i showing constant output frame drops), but it was unrelated to compton (but maybe related to dc=1 as you said). I solved it switching hwdec from vdpau-copy to vaapi-copy. If you want to try reproduce, this is my mpv.conf

• profile=gpu-hq
• gpu-api=vulkan
• gpu-context=x11vk
• spirv-compiler=auto
• hwdec=vaapi-copy
• hwdec-codecs=all
• scale=ewa_lanczossharp
• cscale=ewa_lanczossharp
• video-sync=display-resample
• interpolation
• tscale=oversample
• ytdl-format=bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best

Video example that stutters: mpv "https://www.youtube.com/watch?v=ZaD5p0IvIvk"

[aufkrawall]

Yeah, I need to check more thoroughly if it's really related to compositors or if they just make it a little bit worse and thus more noticeable. I already tried vaapi x11egl and software decoding + Vulkan, both stutter identically.
I'm having the bad suspicion that there might be a general issue with video-sync=display-resample and atomic modesetting drivers, as there are also reports for Intel.

[aufkrawall]

Good news: I found out that --vsync=drmdoesn't suffer the stutter issue with mpv + amdgpu.dc=1, unlike the other offered vsync methods (apart from TearFree).

Thus, could you please activate it again by default for compiling, @yshui ?

[clapbr]

Good news: I found out that --vsync=drmdoesn't suffer the stutter issue with mpv + amdgpu.dc=1, unlike the other offered vsync methods (apart from TearFree).

Thus, could you please activate it again by default for compiling, @yshui ?

I dont had mpv problems but I was curious to see how vsync=drm performs and it seems to be very good on every scenario I tried. Def worthy including it by default unless there is a known big issue with it.

[aufkrawall]

Good news: I found out that --vsync=drmdoesn't suffer the stutter issue with mpv + amdgpu.dc=1, unlike the other offered vsync methods (apart from TearFree).
Thus, could you please activate it again by default for compiling, @yshui ?

I dont had mpv problems but I was curious to see how vsync=drm performs and it seems to be very good on every scenario I tried. Def worthy including it by default unless there is a known big issue with it.

Uhm, now that you say it: It seems to crash Xorg each time I minimize a window with unredir-if-possible = true. :(

[yshui]

@aufkrawall --vsync=drm is a pretty terrible hack so I am reserved about enabling it even if it works for some users.

[aufkrawall]

Yeah, I wouldn't have posted it if I discovered the crash issue earlier.

Talking about vsync: Since you evaluate to restructure a lot of Compton, could you also take a look at vsync? vsync = opengl has the lowest input lag of the available modes, but it's still significantly higher than Gnome-Mutter.

[yshui]

There are also people reporting vsync = opengl not working for them. Honestly, I think opengl-swc is the best option in terms of compatibility. Do you have a bad experience with that option?

I'm not very sure what you mean by input lag. Do you mean the delay between input (say, key press) and the reaction? Is there a concrete way to measure that? Is it the same for all applications?

[clapbr]

Simplest way is dragging windows, but even by just moving the cursor I can feel more lag with opengl-swc/mswc/oml than with opengl or drm

[aufkrawall]

Yes, latency of render output because of vsync frame queue length.
Vsync queue latency (which of course affects input latency) can be tested relatively well by dragging windows with a mouse with a proper sensor, disabled cursor acceleration (libinput flat profile) and not too high sensitivity. You can see how far the window is lagging behind the cursor when doing so.

opengl and drm have the same latency (I suspect at least 2 frames), while opengl-oml and opengl-swc feel even less direct (probably at least 3 frames delay). Gnome-Mutter feels more direct, like 1 frame delay (or definitely less than drm and opengl).
When you start Compton with vblank_mode=0 and vsync = none, there is zero additional latency caused by compositing.

[yshui]

That is interesting. @clapbr @aufkrawall what are your drivers again?

[aufkrawall]

amdgpu + radeonsi of mesa for Polaris GPU (recent git versions). I think the same applies to Intel i915 + i965 of mesa.

[yshui]

@aufkrawall If I understand correctly, what you observe is that when you move window around using your pointer, the window will lag behind the pointer for about 2 frames?

Correct me if I'm wrong, but I think there is not such thing as a "vsync queue". If we use double buffer, the number of queued frames should be exactly 1. However, it is possible there are queued render commands in the GPU, and because it is not properly flushed when we swap buffer, causing the output to lag. (Better explanation can be found here: https://www.khronos.org/opengl/wiki/Swap_Interval#GPU_vs_CPU_synchronization)

But that is purely my guess.

So, with that in mind, I digged around in the source code, and found a undocumented option, --vsync-use-glfinish, which might help, can you give it a try.

[9ary]

Yeah, I can confirm the latency issues. I think it's noteworthy that vsync=drm and vsync=opengl have much lower latency, but they both show a consistent tear near the top of the screen (kinda hard to see under most circumstances).
The latency with oml and swc might be related to whatever the present extension is doing. It is also visible in this minimal compositor test code. It will copy the focused window at startup. Try running it with and without vblank_mode=0 to compare, but make sure you don't have another compositor running.

[clapbr]

So, with that in mind, I digged around in the source code, and found a undocumented option, --vsync-use-glfinish, which might help, can you give it a try.

briefly tried it
compton --vsync=opengl-swc --vsync-use-glfinish // couldnt feel a difference
compton --vsync=opengl --vsync-use-glfinish // starts constant stutter/low fps
compton --vsync=drm --vsync-use-glfinish // starts constant stutter/low fps

[aufkrawall]

@Streetwalrus

I think it's noteworthy that vsync=drm and vsync=opengl have much lower latency, but they both show a consistent tear near the top of the screen (kinda hard to see under most circumstances).

Are you sure that DRI3 is working correctly for you? At least opengl (haven't tested drm that much) definitely doesn't show any tearing here with AMD & DRI3.

@clapbr

compton --vsync=opengl-swc --vsync-use-glfinish // couldnt feel a difference

Are you sure? To me it feels like it reduces input latency to that of opengl.

compton --vsync=opengl --vsync-use-glfinish // starts constant stutter/low fps

Can confirm that.

It looks like vsync = opengl-swc doesn't show the stutter in mpv afterall, and thanks to --vsync-use-glfinish it's also usable for me regarding latency. Have to test it a bit further to be certain though.

For some weird reason, --vsync-use-glfinishmust be defined at launch and doesn't work in a config file.

[9ary]

Are you sure that DRI3 is working correctly for you? At least opengl (haven't tested drm that much) definitely doesn't show any tearing here with AMD & DRI3.

Absolutely certain.

[aufkrawall]

Absolutely certain.

Huh, weird. I once checked it on my Haswell / Broadwell (?) Atom and it seemed to work normally. That was quite some time ago though, and I guess it doesn't matter much if that vsync API isn't recommended in the first place.

[9ary]

It could be related to my 4k monitor. Looking at the timings, the vblank interval is relatively shorter compared to 1080p modes, so it's not unlikely that the overhead of waiting for vblank, and then performing a full screen copy on a buffer that is 4x larger misses it consistently. I'm pretty sure the Present extension is smarter than that, and copies the buffer before vsync comes in.

[yshui]

For some weird reason, --vsync-use-glfinish must be defined at launch and doesn't work in a config file.

@aufkrawall Yes, because it is not a config option, only a command line option. Not sure why the original developers didn't document it.

[yshui]

@Streetwalrus @aufkrawall I can confirm vsync = opengl indeed cause tearing on my intel graphics card.

[aufkrawall]

@aufkrawall Yes, because it is not a config option, only a command line option. Not sure why the original developers didn't document it.

If it turns out that it doesn't produce any trouble, perhaps it would be good to automatically enable it when at least vsync = opengl-swc is used? It definitely helps in my case.

Of course it would still be fantastic if you could manage to reduce latency even further. :)

Can vsync = opengl-mswc be considered redundant?

[yshui]

--vsync-use-glfinish causes compton to use 100% CPU here (nvidia driver). So I guess no, can't enable it by default. But I think I need to investigate what is happening.

[yshui]

Looks like nvidia driver uses busy wait for glFinish() :(

[yshui]

I think I might be able to do something about this. This will make the drawing logic a bit more complicated, but maybe it will be worth it.

[yshui]

I made a page explaining why the lag happens: https://github.com/yshui/compton/wiki/Vsync-Lag-Explained

Conclusion is the glFinish is not good enough, some other way is needed for waiting on SwapBuffers

[aufkrawall]

Funny, there is similar (not saying it would be related) issue with Nvidia Vulkan driver & mpv:
mpv-player/mpv#6172
It's so hurtful, I'm so glad I sold my Nvidia card...

[aufkrawall]

Good news: The fix for the initially reported issue will be in 4.21 kernel:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.21-wip&id=0e65ba74dbd61f54f2dc74035d07490d5fd99a38

However, I've noticed that vsync = opengl-swc doesn't get entirely rid of the stutter problem in mpv with amdgpu.dc=1. It's basically gone with hardware video decoding, but not with software decoding. This luckily doesn't apply to the TearFree method described above, I'm still convinced it's entirely free of stutter.

@yshui Would it be possible to implement an option to run a command when Compton enables and disables unredir? This way TearFree could be automatically enabled and disabled for fullscreen windows via xrandr.

[9ary]

@aufkrawall does mpv report the jitter (shift+i)? Or is it compton itself that's stuttering (run with GALLIUM_HUD=fps)?

[aufkrawall]

The issue doesn't exist for the performance metrics, Compton fps are stable and vsync jitter in mpv very low. It's also quite hard to perceive, it's a sporadic micro stutter (not caused by e.g. RedShift, this is another issue). The issue happens only with amdgpu.dc=1 + Compton vsync + mpv.

It doesn't happen (aka is totally smooth) with:
Gnome-Mutter
Compton + TearFree instead of Compton vsync
mpv in fullscreen without any compositor
any other application than mpv, e.g. Firefox + Compton vsync looks totally smooth
amdgpu.dc=0

I suppose it's some specific weirdness of the vsync part inside the display driver.

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.

[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.

[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