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.
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).
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?
No, this will not increase the amount of kernel panics you see. It just makes them more informational to the average person. Technical folks can disable it, non-technical folks won’t know how to enable it, so on by default it is.
I hope this isn’t going to be the default. I know, the average granny might prefer to have a BSOD with a QR code, but I think a lot of the people who are more tech-savvy, like me, would prefer to see log messages when booting because then you could see which service failed and why or why it’s all of a sudden taking so long to boot. That’s also why I choose not to have a splash screen when booting.
Anyways, this BSOD thing doesn’t apply to me because I use Gentoo with OpenRC.
I just wish they would use another name for it, it’s linux here no need to copy windows slang! Or use another color! (I hope they’ll update it to make it a customizable color)
Fun fact: The Windows BSOD colour was as easy as adding a couple of lines to a .INI file for a long time. Then, as they tend to do, they made it more difficult, but it was still possible. Third party tools were written to do the work.
Very recent MS Windows I have no idea about. My search-fu is failing me.
Anyway, my point is that the "two lines in a config file" method would be nice.
Knowing systemd though, it'll be "send some kind of message into a /proc pseudo-file", or a sub-sub-sub-command of one of the many systemd* commands which ultimately does the same thing.
I love this! Not only for the comedic value, but throwing kernel oopses on-screen when they can’t be easily captured when unprepared would be of great help in solving system problems. Unlike the cryptic messages Windows displays, Linux kernel messages are quite useful.
Yep. In fact my comment seemed so clear to me that I assumed it was some kind of joke, but looking at the votes, maybe swapfiles aren't as well known as I thought.
Um, you really need to read the entire phrase and not pick out only what you want from it. 😃
Swap can make a system slower to OOM kill, since it provides another, slower source of memory to thrash on in out of memory situations
It means that if you try to use it as a source of memory, when you run out of actual RAM it will make your system almost completely unresponsive due to disk thrash, instead of allowing the kernel to just kill the process that’s eating your RAM. So you’ll just end up hard-booting system.
Yes, and that’s a good thing if you don’t want it to start killing processes. You have that extra time/space to deal with the out-of-memory condition yourself.
Or you can ignore that condition and continue using the system in a degraded state, with swap as “disk RAM”.
Like I said, the system will be almost completely unresponsive due to disk access being several orders of magnitude lower than RAM and allocation thrashing… you won’t be able to do much, the mouse, keyboard and display will react extremely slowly. There may be situations where you’d prefer this to an OOM kill, for example if you’re running a test or experiment where you’d rather have it finish even if it takes a very long time rather than lose the data. But if you’re a regular desktop user or server admin you’ll probably just reboot.
Back about two decades when I was using Windows and it was till easily customisable, I changed the bsod colour to red for funsies. Windows being Windows crashed and went to my red screen of death - my ex's cousin saw it and thought it was something really really bad, "Wow, a red screen, never seen that before. Must be even worse than blue". No mate, I just customise the shit out of anything I touch 😅
The thought of someone’s Linux install failing catastrophically, displaying a “MSoS”, then the user switching back to the is MS OS because of it is funny to me.
Correct me if I’m wrong but isn’t this basically just better error reporting? It’s not like it’s gonna crash more often, it will just actually show log info if something catastrophic happens.
that’s the goal, they also gonna implement the QR code, but not like the crappy of QR code on windows(that send you to a suppirt page with a dozen of possible sulution, where nothing work), the qr code is going translate to the kernel panic message, i liked, i can scan the qr code and search the error on my cell
A new component “systemd-bsod” has been added to show logged error messages full-screen if they have a “LOG_EMERG” log level. This is intended as a tool for displaying emergency log messages full-screen on boot failures. Yes, BSOD in this case short for “Blue Screen of Death”. This was worked on as part of Outreachy 2023. The systemd-bsod will also display a QR code for getting more information on the error causing the boot failure.
Hibernation into swap files backed by Btrfs are now supported.
Actually looking forward to the btrfs swapfile hibernation; I have tried setting it up on my machine before but the documentation was never clear on whether it would work (or why mine wasn’t).
Is there not issues with filling up the NVRAM with efi entries, even if you’re deleting old ones? I’ve bricked a computer by distrohopping so many times it couldn’t write new entries.
This latest UKI work for Fedora will lead to better UEFI Secure Boot support, better supporting TPM measurements and confidential computing, and a more robust boot process.
and HOPEFULLY lead to a less jerky-flashy-switchy boot xperience, looks like a Vegas light show at present. switched to systemd-boot, but it’s only a tiny bit better, still switches modes/blanks screen like five times.
Omg yes, I hate those. I’m sitting here thinking it’s probably one of those simple things that scares people away from Linux…“Oh god, I see black text on white background. Abort, abort, ABORT!!”
yeah, if you don’t have an encrypted drive (which I’m gonna do on a laptop NEVER) on some OEMs this can look semi-seamless.
here’s what it looks like on a laptop:
OEM logo
screen goes blank, backlight off
light on, OEM logo
blank screen
decrypt password
blank screen
loading spinner with OEM logo
gdm/sddm login screen
blank screen
9a. (sddm) loading animation
9b. (sddm) jerk when fractional scaling kicks in
and finally there’s the desktop
with additional mode switching interjected and occasionally the horror that is GRUB inserts a ‘Loading blah blah’ text message; thankfully we’re getting rid of that.
My HP crapbook doesn’t have this OEM logo bullshit. Only the windows bootloader shows it, and the logo file is stored in the BGRT. So I don’t think I’m affected unless the WBM or systemd-boot have this vuln.
Mine:
<span style="color:#323232;">1. Screen turns on
</span><span style="color:#323232;">2. I pick EndeavorOS in systemd-boot
</span><span style="color:#323232;">3. It starts spitting out logs (I love this behavior)
</span><span style="color:#323232;">4. It switches modes once the backlight is loaded
</span><span style="color:#323232;">5. I log in
</span><span style="color:#323232;">6. KDE loads
</span>
I will never understand people who install Plymouth, it just adds complexity in the boot process. If your distro installs this then I understand why: so it doesn’t look like you’re “hacking the government”. If your distro doesn’t install it and you install it then you probably picked the wrong distro.
phoronix.com
Hot