Comments (96)
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.
from picom.
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.
from picom.
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.
from picom.
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.
from picom.
The fix for the problem originally discussed is now in linux 5.0-rc1.
from picom.
So opengl-swc does work? I will file this under performance problems.
Also, do you still get tearing with openly vsync?
from picom.
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.
from picom.
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.
from picom.
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.
from picom.
According to @jm33-m0, this also happens on intel card. Refer to #26 for details about his hardware and configuration.
from picom.
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.
from picom.
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.
from picom.
I already tried drm-next-4.21-wip a few days ago and it unfortunately didn't help with my issue.
from picom.
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.
from picom.
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.
from picom.
One other ugly workaround would be to turn off the hardware cursor.
This blows my mind. How is hardware cursor involved in this?
from picom.
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.
from picom.
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.
from picom.
Comment from dev about the HW cursor issue https://bugs.freedesktop.org/show_bug.cgi?id=106446#c2
from picom.
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
from picom.
This is truly great. :)
However, I just noticed another amdgpu.dc bug which introduces stuttering in mpv when at least Compton is active. partyruined
from picom.
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"
from picom.
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.
from picom.
Good news: I found out that --vsync=drm
doesn'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 ?
from picom.
Good news: I found out that
--vsync=drm
doesn'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.
from picom.
Good news: I found out that
--vsync=drm
doesn'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
. :(
from picom.
@aufkrawall --vsync=drm
is a pretty terrible hack so I am reserved about enabling it even if it works for some users.
from picom.
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.
from picom.
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?
from picom.
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
from picom.
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.
from picom.
That is interesting. @clapbr @aufkrawall what are your drivers again?
from picom.
amdgpu + radeonsi of mesa for Polaris GPU (recent git versions). I think the same applies to Intel i915 + i965 of mesa.
from picom.
@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.
from picom.
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.
from picom.
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
from picom.
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.
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-glfinish
must be defined at launch and doesn't work in a config file.
from picom.
Are you sure that DRI3 is working correctly for you? At least
opengl
(haven't testeddrm
that much) definitely doesn't show any tearing here with AMD & DRI3.
Absolutely certain.
from picom.
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.
from picom.
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.
from picom.
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.
from picom.
@Streetwalrus @aufkrawall I can confirm vsync = opengl
indeed cause tearing on my intel graphics card.
from picom.
@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?
from picom.
--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.
from picom.
Looks like nvidia driver uses busy wait for glFinish()
:(
from picom.
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.
from picom.
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
from picom.
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...
from picom.
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.
from picom.
@aufkrawall does mpv report the jitter (shift+i)? Or is it compton itself that's stuttering (run with GALLIUM_HUD=fps
)?
from picom.
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.
from picom.
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).
from picom.
Ok, but why is it not enabled by default in games? I don't think they all take that particular mesa behavior into account.
from picom.
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).
from picom.
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.
from picom.
Both with and without full screen. Under compton, you need to exclude Firefox from or disable unredir-if-possible.
from picom.
@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
.
from picom.
Yep, that's pretty much what's happening.
from picom.
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).
from picom.
@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.
from picom.
@Streetwalrus Would you like to make a pull request for explicitly setting swap interval?
from picom.
@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).
from picom.
@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.
from picom.
I know for certain that mesa itself supports both, I don't think anything else does.
from picom.
@Streetwalrus Good ahead then. But don't remove the opengl-mswc
option, just make it do the same thing as opengl-swc
from picom.
Yeah that's the plan.
from picom.
Maybe also print a message when used that mswc
is considered obsolete? :)
from picom.
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.
from picom.
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.
from picom.
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.
from picom.
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.
from picom.
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.
from picom.
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.
from picom.
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).
from picom.
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.
from picom.
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.
from picom.
I'll try it asap, currently stuck with no monitor for my desktop.
from picom.
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.
from picom.
@Streetwalrus Interesting. What is different about this monitor?
from picom.
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.
from picom.
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.
from picom.
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.
from picom.
the following patch fixes compton lag in linux 4.20.x series i tested it:
https://bugs.freedesktop.org/attachment.cgi?id=142574
from picom.
@Streetwalrus Maybe this issue can be closed?
from picom.
Yep, I was going to but was waiting for confirmation from others.
from picom.
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 &
from picom.
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 ;)
from picom.
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.
from picom.
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.
from picom.
@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.
from picom.
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.
from picom.
Typo: For the open source radeon driver setting "call glx swap buffers then call glx copy pixels FRONT TO BACK" is optimal.
from picom.
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.
from picom.
@zkeng Which version of compton are you using? I am confident that --glx-copy-from-front
stopped doing anything since v3.
from picom.
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.
from picom.
No worries
from picom.
Related Issues (20)
- bug report HOT 1
- Freesync doesn't work after big system and Xfce update on Manjaro Testing.
- picom next (animations) crashes on startup
- Animation crops right and bottom borders HOT 1
- Picom spams sgi_video_sync_scheduler_callback with latest nvidia driver HOT 22
- Cannot disable frame blur from firefox pop-up HOT 6
- picom 9.1 - X error 8 MATCH request 139 minor 4 HOT 7
- Picom not launcing no matter what. Instead i get this error: HOT 4
- Refuse to run under wayland HOT 9
- After enabling second monitor, the new area is not rendered correctly HOT 12
- Crash when `gpg-agent` calls `pinentry-gtk-2` HOT 4
- Unable to remove polybar shadow HOT 5
- Picom causes noticeable framerate stutters HOT 2
- [feature] [RFC] universal window rules HOT 6
- `id` pattern does not work for `opacity-rule` HOT 3
- 10 bit colour depth breaks picom ? HOT 3
- High CPU usage when screen is off HOT 3
- Long-running picom causes system slowdown (high CPU usage of Xorg process) HOT 31
- Changing workspace in i3 doesn't trigger window focus animation on target workspace window HOT 2
- Slow release pace HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from picom.