Triple Buffering Likely Not Landing Until GNOME 42

[pal666]

That would introduce 1 frame of latency, or 16,7 ms at worst on a 60 hz monitor. On the desktop that shouldn't be that noticeable, or is it?

it would be extra 16ms on top of existing latency. and yes it's noticeable

[david-nk]

Triple buffering introduces additional latency, but I don't see how it supposed to cause more work. Rather, it likely works because it prepares two instead of one frame in advance. So if one frame is late (that is to say, the third frame we were working on moved up to the second position in the buffer), the DE will immediately start working on the next, thus keeping the GPU non-idle for a longer period of time, which should cause it to clock up.

With standard double buffering, if a frame is late, it's the frame we wanted to display next. So there is no choice other than to skip it and wait for next vblank. All the skipping lowers the GPU workload artificially, which causes the driver to think it can stay at the lowest clock rates.

[mihau]

Triple buffering introduces additional latency, but I don't see how it supposed to cause more work. Rather, it likely works because it prepares two instead of one frame in advance.

Again, this is a misconception. There is no 2 frames being prepared in advance, the most recent completed frame is always displayed.
One way to think about it, is that when the gpu can keep up, only 2 out of 3 buffers are actually being used at any given moment (one is displayed, other is being rendered to). The third buffer stores the previous displayed frame. Only when the GPU can't keep up does the third buffer come into play - one is displayed, one is waiting to be displayed, while the gpu is rendering to the third.
But you are correct in saying that it doesn't cause more work.

[reba]

This sounds like a "granny fix" to me: step on the car's accelerator pedal and hit it to the floor because in first gear you stall the engine as you are unable to control it as delicately as it needs it to be. It's a hack.

[curfew]

That would introduce 1 frame of latency, or 16,7 ms at worst on a 60 hz monitor. On the desktop that shouldn't be that noticeable, or is it?

Actually a couple years back there was a lot of work on improving performance by optimizing away some of these weird single-frame latencies. So now this patch is looking undo some of that work.

[shrisha]

You guys just speculating and all this talk how they should do this and that. If you so smart just make your own great DE and show other that you are not just trolling around. I'm not a dev, may be little more advanced than simple user and want to speak only from my own experience, I'm using this MR for past few month and only what I can say that this MR makes my desktop buttery smooth like nothing does before.

[binarybanana]

The whole issue is that it is too efficient causing the GPU to run into a lower clock energy saving mode.

That's ridiculous, my composited Xorg dual monitor (2x1080p) setup reliably renders at a constant 75fps on my mid range Intel CPU with no missed frames and it does that at the highest powersaving levels (350MHz), too. In fact I've never seen in in any other state because I have a dGPU for when I need the FLOPS.

[binarybanana]

Actually a couple years back there was a lot of work on improving performance by optimizing away some of these weird single-frame latencies. So now this patch is looking undo some of that work.

No, that's ot what this patch does, or at least I assume so because I didn't check. But if it works as I'm thinking it does it will reduce latency, rather than increase it. More buffers reduce latency?
Sounds crazy? Well, think about what happens when you miss your render target by 1-2ms. You flip the buffer and then... rendering stalls because the front buffer is being scanned out and can't be swapped out with the fresh frame for another 13-14ms (next vblank) and since there are only two buffers involved in double buffering (hence the name, lol) that means you don't get to process and render user input while you wait for the buffer flip at which point you finally have a buffer to render into. If you only miss the target once that's not a big deal, but if you keep missing it locks you to half, third or worse the refresh rate. Meanwhile, if you have a third buffer there is no contention on the buffers so rendering can happen earlier and more often. You never have to wait for the front buffer to get released to start rendering the next frame.
I'm not sure how to make it more clear, but it should be obvious that you get faster response when input is processed earlier, frames rendered with less delay (delay ~= latency} and at higher frame rates. Result is fresher input and smoother everything.

Caveat: latency indeed increases if you let the GPU render ahead until it's blocked like in the double buffered case. Solution: Just don't do that.

[JoshuaAshton]

The real solution is to just move the time you prepare for vblank back, not to introduce multiple frames of latency for no reason

[sarmad]

The real solution is to just move the time you prepare for vblank back, not to introduce multiple frames of latency for no reason

The actual real solution is to not render window areas when they are hidden behind other windows like gnome currently does.