autotldr@lemmings.world
on 09 Dec 2023 03:00
nextcollapse
This is the best summary I could come up with:
It looks like GNOME 46 might finally see the dynamic triple buffering support merged for Mutter to enhance the performance particularly for systems with integrated graphics.
Ubuntu and Debian have been carrying the GNOME Mutter dynamic triple buffering patches for years that have been maintained by Canonical’s Daniel van Vugt.
Van Vugt commented this morning in an Ubuntu desktop status update: “Completed a redesign for mutter 46 that should get us closer to merging much sooner than carrying on with unified buffer management…Triple buffering is now out of draft status and ready to merge.”
He added this week in the merge request: “[KMS unify buffer management for all plane types] has been dropped.
FTR., I hope to get [Wayland direct scanout for cropped and scaled surfaces] into a mergable state soon and was worrying that would step on your toes here, but now it looks like it should be pretty compatible.”
We’ll see if after 3+ years of work if Mutter dynamic triple buffering is finally ready for upstream in GNOME 46.
The original article contains 305 words, the summary contains 172 words. Saved 44%. I’m a bot and I’m open source!
Juujian@lemmy.world
on 09 Dec 2023 03:12
nextcollapse
That sounds cool… Wish the article said what it does.
AlmightySnoo@lemmy.world
on 09 Dec 2023 03:41
collapse
Double and triple buffering are techniques in GPU rendering (also used in computing, up to double buffering only though as triple buffering is pointless when headless).
Without them, if you want to do some number crunching on your GPU and have your data on the host (“CPU”) memory, then you’d basically transfer a chunk of that data from the host to a buffer on the device (GPU) memory and then run your GPU algorithm on it. There’s one big issue here: during the memory transfer, your GPU is idle because you’re waiting for the copy to finish, so you’re wasting precious GPU compute.
So GPU programmers came up with a trick to try to reduce or even hide that latency: double buffering. As the name suggests, the idea is to have not just one but two buffers of the same size allocated on your GPU. Let’s call them buffer_0 and buffer_1. The idea is that if your algorithm is iterative, and you have a bunch of chunks on your host memory on which you want to apply that same GPU code, then you could for example at the first iteration take a chunk from host memory and send it to buffer_0, then run your GPU code asynchronously on that buffer. While it’s running, your CPU has the control back and it can do something else. Here you prepare immediately for the next iteration, you pick another chunk and send it asynchronously to buffer_1. When the previous asynchronous kernel run is finished, you rerun the same kernel but this time on buffer_1, again asynchronously. Then you copy, asynchronously again, another chunk from the host to buffer_0 this time and you keep swapping the buffers like this for the rest of your loop.
Now some GPU programmers don’t want to just compute stuff, they also might want to render stuff on the screen. So what happens when they try to copy from one of those buffers to the screen? It depends, if they copy in a synchronous way, we get the initial latency problem back. If they copy asynchronously, the host->GPU copy and/or the GPU kernel will keep overwriting buffers before they finish rendering on the screen, which will cause tearing.
So those programmers pushed the double buffering idea a bit further: just add an additional buffer to hide the latency from sending stuff to the screen, and that gives us triple buffering. You can guess how this one will work because it’s exactly the same principle.
QuazarOmega@lemy.lol
on 09 Dec 2023 10:07
nextcollapse
I love this explanation, I thought I’d never understand
MonkderZweite@feddit.ch
on 09 Dec 2023 13:18
collapse
And why does a desktop environment need to do that?
jmcs@discuss.tchncs.de
on 09 Dec 2023 13:34
nextcollapse
To reduce input lag and provide smoother visuals.
MonkderZweite@feddit.ch
on 10 Dec 2023 14:06
collapse
You say the animations are too much?
jmcs@discuss.tchncs.de
on 10 Dec 2023 14:24
nextcollapse
If by animations you mean smoothly moving the mouse and windows while badly optimized apps and websites are rendering, yes.
Lol, why own up to adding animations the system can’t handle when you can blame app and web devs? Gnome users always know where the blame should be laid, and it’s never Gnome.
Chewy7324@discuss.tchncs.de
on 09 Dec 2023 15:19
nextcollapse
If the system can’t keep up with the animation of e.g. Gnome’s overview, the fps halfes because of double buffered vsync for a moment. This is perceived as stutter.
With triple buffer vsync the fps only drop a little (e .g 60 fps -> 55 fps), which isn’t as big of drop of fps, so the stutter isn’t as big (if it’s even noticeable).
MonkderZweite@feddit.ch
on 10 Dec 2023 14:00
collapse
Maybe the animation a bit simpler…?
Less animation is usually better UX in something often used, if it’s not to hide slowness of someting else.
AlmightySnoo@lemmy.world
on 09 Dec 2023 20:37
collapse
Biased opinion here as I haven’t used GNOME since they made the switch to version 3 and I dislike it a lot: the animations are so slow that they demand a good GPU with high vRAM speed to hide that and thus they need to borrow techniques from game/GPU programming to make GNOME more fluid for users with less beefy cards.
Not only slow, it drops frames constantly. Doesn’t matter how good your hardware is.
There’s always the Android route, why fix the animations when you can just add high framerate screens to all the hardware to hide the jank. Ah, who am I kidding, Gnome wouldn’t know how to properly support high framerates across multiple monitors either. How many years did fractional scaling take?
1984@lemmy.today
on 09 Dec 2023 08:10
nextcollapse
There is already a package for this in arch AUR you can install:
Canonical have had it in Ubuntu for years, but it’s taken them a while to get it to a point where it could be upstreamed. That’s what this news is: that Canonical’s patch is finally all clear to be merged.
Abracadaniel@hexbear.net
on 09 Dec 2023 16:27
nextcollapse
Damn, they might pull me back from kde plasma.
kawa@reddeet.com
on 09 Dec 2023 17:25
nextcollapse
I genuinely tried Gnome and started to like it but a very minor update broke all of my QoL extensions and only 1/8th of them were updated. It’s lacking so many features that it’s just a bad DE all around : snapping windows in quarters anyone ? Why isn’t it already an option ?
GNOME devs need to touch grass and listen to the actual users.
Fredol@lemmy.world
on 09 Dec 2023 19:27
nextcollapse
Gnome devs will never listen to criticism. Even if you do a MR it might get denied because it contraricts with the “Gnome way”. Just use KDE and live an happy life. KDE can be easily modified to look like Gnome and have all the QOLs you need.
AnUnusualRelic@lemmy.world
on 10 Dec 2023 14:31
collapse
It’s ok, we’re not kink shaming here.
unionagainstdhmo@aussie.zone
on 09 Dec 2023 21:33
nextcollapse
To be fair the extension developers were given quite a while to update their extensions to use JavaScript modules instead of the custom GNOME solution. This was actually a change for the better and unlikely to happen again which should make extension development easier. As for better tiling look up their mosaic thing which was announced a while ago, though I’m unsure as to how soon that will come out.
Also try to remember that GNOME is developed mostly by volunteers who frankly owe you nothing
chitak166@lemmy.world
on 09 Dec 2023 22:00
nextcollapse
GNOME devs need to touch grass and listen to the actual users.
I totally agree. However, interacting with any gnome devs is like pulling teeth. They keep making bad decisions to be ‘different’ and make their jobs easier, then when those decisions turn out to be bad they have to walk them back but never admit fault.
Being able to move the dock is fine example of this.
It’s like they want Apple’s lack of customization but can’t provide a competitive default (because they suck at their jobs.)
Lol, how does this change the fact their work stinks? Maybe if they didn’t suck at designing the hate would stop? Nah, guilt trip the users instead, that’ll fix it. Free crap is still crap, and pointing it out isn’t a sin. If the devs can’t deal with that, maybe they should go home and cry about it instead of further shitting up the code.
Devs don’t owe users anything? Guess what, users don’t owe devs shit either. If they don’t like criticism, tough tittys, cause shit code will be criticized, which is why Gnome is still considered a joke.
1995ToyotaCorolla@lemmy.world
on 10 Dec 2023 15:53
nextcollapse
I don’t like the insinuation that because gnome devs are volunteers they are somehow beyond criticism
You can volunteer on a project and still do a bad job, or need corrective action, or maybe even a little feedback. That’s not a bad thing. Nobody can make the right decision 100% of the time, and you need an outside perspective to see that.
One thing where you should draw the line is when that criticism starts to become abusive, but that’s something nobody should have to put up with, not just volunteers.
Correct, but I’m seeing a lot of abusive criticism in this thread, where we bash the devs rather than the code. That’s where I draw the line.
Also, when criticizing work, it should be kept constructive rather than just hurling generic statements and insults. A well formulated thought is more likely to change things than a toxic, meaningless rage-induced rant.
cbarrick@lemmy.world
on 10 Dec 2023 17:25
collapse
These are volunteers that work for free, right?
Some are working for free, sure. But mainly GNOME is developed by Red Hat and Canonical, afaict.
threaded - newest
This is the best summary I could come up with:
It looks like GNOME 46 might finally see the dynamic triple buffering support merged for Mutter to enhance the performance particularly for systems with integrated graphics.
Ubuntu and Debian have been carrying the GNOME Mutter dynamic triple buffering patches for years that have been maintained by Canonical’s Daniel van Vugt.
Van Vugt commented this morning in an Ubuntu desktop status update: “Completed a redesign for mutter 46 that should get us closer to merging much sooner than carrying on with unified buffer management…Triple buffering is now out of draft status and ready to merge.”
He added this week in the merge request: “[KMS unify buffer management for all plane types] has been dropped.
FTR., I hope to get [Wayland direct scanout for cropped and scaled surfaces] into a mergable state soon and was worrying that would step on your toes here, but now it looks like it should be pretty compatible.”
We’ll see if after 3+ years of work if Mutter dynamic triple buffering is finally ready for upstream in GNOME 46.
The original article contains 305 words, the summary contains 172 words. Saved 44%. I’m a bot and I’m open source!
That sounds cool… Wish the article said what it does.
Double and triple buffering are techniques in GPU rendering (also used in computing, up to double buffering only though as triple buffering is pointless when headless).
Without them, if you want to do some number crunching on your GPU and have your data on the host (“CPU”) memory, then you’d basically transfer a chunk of that data from the host to a buffer on the device (GPU) memory and then run your GPU algorithm on it. There’s one big issue here: during the memory transfer, your GPU is idle because you’re waiting for the copy to finish, so you’re wasting precious GPU compute.
So GPU programmers came up with a trick to try to reduce or even hide that latency: double buffering. As the name suggests, the idea is to have not just one but two buffers of the same size allocated on your GPU. Let’s call them
buffer_0andbuffer_1. The idea is that if your algorithm is iterative, and you have a bunch of chunks on your host memory on which you want to apply that same GPU code, then you could for example at the first iteration take a chunk from host memory and send it tobuffer_0, then run your GPU code asynchronously on that buffer. While it’s running, your CPU has the control back and it can do something else. Here you prepare immediately for the next iteration, you pick another chunk and send it asynchronously tobuffer_1. When the previous asynchronous kernel run is finished, you rerun the same kernel but this time onbuffer_1, again asynchronously. Then you copy, asynchronously again, another chunk from the host tobuffer_0this time and you keep swapping the buffers like this for the rest of your loop.Now some GPU programmers don’t want to just compute stuff, they also might want to render stuff on the screen. So what happens when they try to copy from one of those buffers to the screen? It depends, if they copy in a synchronous way, we get the initial latency problem back. If they copy asynchronously, the host->GPU copy and/or the GPU kernel will keep overwriting buffers before they finish rendering on the screen, which will cause tearing.
So those programmers pushed the double buffering idea a bit further: just add an additional buffer to hide the latency from sending stuff to the screen, and that gives us triple buffering. You can guess how this one will work because it’s exactly the same principle.
I love this explanation, I thought I’d never understand
And why does a desktop environment need to do that?
To reduce input lag and provide smoother visuals.
You say the animations are too much?
If by animations you mean smoothly moving the mouse and windows while badly optimized apps and websites are rendering, yes.
Lol, why own up to adding animations the system can’t handle when you can blame app and web devs? Gnome users always know where the blame should be laid, and it’s never Gnome.
If the system can’t keep up with the animation of e.g. Gnome’s overview, the fps halfes because of double buffered vsync for a moment. This is perceived as stutter.
With triple buffer vsync the fps only drop a little (e .g 60 fps -> 55 fps), which isn’t as big of drop of fps, so the stutter isn’t as big (if it’s even noticeable).
Maybe the animation a bit simpler…?
Less animation is usually better UX in something often used, if it’s not to hide slowness of someting else.
Biased opinion here as I haven’t used GNOME since they made the switch to version 3 and I dislike it a lot: the animations are so slow that they demand a good GPU with high vRAM speed to hide that and thus they need to borrow techniques from game/GPU programming to make GNOME more fluid for users with less beefy cards.
Not only slow, it drops frames constantly. Doesn’t matter how good your hardware is.
There’s always the Android route, why fix the animations when you can just add high framerate screens to all the hardware to hide the jank. Ah, who am I kidding, Gnome wouldn’t know how to properly support high framerates across multiple monitors either. How many years did fractional scaling take?
There is already a package for this in arch AUR you can install:
aur.archlinux.org/…/mutter-dynamic-buffering
I used to install this (it replaces mutter) but didn’t notice any difference in my system.
I think it makes a big difference on some systems though, since I saw other people absolutely love it.
There’s a Fedora copr with the triple buffering patches and it did improve the perceived smoothness of Gnome’s animations on my 8th gen Intel CPU.
It was especially noticeable if the system was limited in power because of running on battery.
I use this package. It makes a difference in games.
Canonical have had it in Ubuntu for years, but it’s taken them a while to get it to a point where it could be upstreamed. That’s what this news is: that Canonical’s patch is finally all clear to be merged.
Damn, they might pull me back from kde plasma.
I genuinely tried Gnome and started to like it but a very minor update broke all of my QoL extensions and only 1/8th of them were updated. It’s lacking so many features that it’s just a bad DE all around : snapping windows in quarters anyone ? Why isn’t it already an option ? GNOME devs need to touch grass and listen to the actual users.
Gnome devs will never listen to criticism. Even if you do a MR it might get denied because it contraricts with the “Gnome way”. Just use KDE and live an happy life. KDE can be easily modified to look like Gnome and have all the QOLs you need.
Oh yeah I’m 100% on KDE now, I switched to Gnome for a little while because it had less bugs on Wayland on nvidia cards
.
It’s ok, we’re not kink shaming here.
To be fair the extension developers were given quite a while to update their extensions to use JavaScript modules instead of the custom GNOME solution. This was actually a change for the better and unlikely to happen again which should make extension development easier. As for better tiling look up their mosaic thing which was announced a while ago, though I’m unsure as to how soon that will come out.
Also try to remember that GNOME is developed mostly by volunteers who frankly owe you nothing
I totally agree. However, interacting with any gnome devs is like pulling teeth. They keep making bad decisions to be ‘different’ and make their jobs easier, then when those decisions turn out to be bad they have to walk them back but never admit fault.
Being able to move the dock is fine example of this.
It’s like they want Apple’s lack of customization but can’t provide a competitive default (because they suck at their jobs.)
You know these are volunteers that work for free, right?
Lol, how does this change the fact their work stinks? Maybe if they didn’t suck at designing the hate would stop? Nah, guilt trip the users instead, that’ll fix it. Free crap is still crap, and pointing it out isn’t a sin. If the devs can’t deal with that, maybe they should go home and cry about it instead of further shitting up the code.
Devs don’t owe users anything? Guess what, users don’t owe devs shit either. If they don’t like criticism, tough tittys, cause shit code will be criticized, which is why Gnome is still considered a joke.
I don’t like the insinuation that because gnome devs are volunteers they are somehow beyond criticism
You can volunteer on a project and still do a bad job, or need corrective action, or maybe even a little feedback. That’s not a bad thing. Nobody can make the right decision 100% of the time, and you need an outside perspective to see that.
One thing where you should draw the line is when that criticism starts to become abusive, but that’s something nobody should have to put up with, not just volunteers.
Correct, but I’m seeing a lot of abusive criticism in this thread, where we bash the devs rather than the code. That’s where I draw the line.
Also, when criticizing work, it should be kept constructive rather than just hurling generic statements and insults. A well formulated thought is more likely to change things than a toxic, meaningless rage-induced rant.
Some are working for free, sure. But mainly GNOME is developed by Red Hat and Canonical, afaict.
Florian Müllner is a Red Hat employee.
Yes, however most GNOME developers are not RedHat / Canonical employees.
Even those that do work for those companies should be treated with dignity. GNOME is free of charge, and no one is obligated to use GNOME.
That wouldn’t be the true gnome experience.
Some gnome changes totally break an smol distro that i was using after that i change to kde until they find a stable point to all extensions