Dynamic Triple Buffering For GNOME Still Being Worked On To Ramp Up The GPU When Needed

[Aryma]

imagine you need 1080ti to run your desktop environment

[leipero]

Meanwhile, when v blank is 0, mutter/gtk applications completely misses animation sometimes..., so there's clearly another issue with it, and possibly the cause of what's happening with v-blank enabled.

[libcg_]

I've seen so many bugs blamed on drivers when it was a Gnome issue. This one included.

[libcg_]

I don't. Triple buffering is desirable even with an hypothetical "perfect" driver that would ramp up clocks to 100% instantly, because it eliminates idle time when vsync was missed. Note that this can happen even with powerful computers, because the system load is unpredictable.

[raster]

That's not how modern GPUs work.
Double buffering is what you want. 1 Buffer for the current frame being displayed and 1 for the rendering frame. They simply swap once a frame is done rendering. If the frame doesn't change the GPU just outputs the current frame buffer. Since the GPU just refuses the buffer until it is swapped, a lot of power is saved. Triple buffering was a method to eliminate tearing in older GPU architectures that couldn't reuse the buffer in hardware. The problem with triple buffer is that you need to render that extra intermediary frame even when there are no changes. This is what causes the extra power and memory usage.

Realistically reducing the rendering pipeline is the best solution to see screen input faster. Otherwise you're just ramping the GPU unnecessarily.

Back then, the buffer being rendered would replace the current buffer even if it wasn't done yet. This is what causes tearing. Triple buffering works around that by always working 1 frame behind so that the back buffer was always a completed frame. Modern systems don't do this and just repeat the current frame when Vsync is in play.

Sorry.. but you're smoking some strong stuff if you think triple buffering has anything to do with stopping tearing. If you're not respecting swap-at-vblank then tearing can and will happen with triple buffering too. It's pointless to do triple buffering through then as double will do. ITriple buffering is about filling in unused render time while the front buffer is still locked (being displayed) and the new backbuffer that is going to become the front is "in flight" but you can't start rendering another frame until the front buffer lock is released. This is often blocked until the screen has finished its screen scan-out and that time then gets unused. This becomes especially bothersome when you are doing partial-updates as this requires buffer age to be known before any render commands are generated and so you can't just queue all the commands to run until the buffer is available to render to. If you do not know which buffer is going to be your new backbuffer yet, you can't know what to render yet. This kind of blocks at the command generation level.

Any driver that swapped buffers in double-buffering without respecting vsync (when asked or by default) was just asking for tearing no matter what and triple buffering doesn't fix it. It's accepting a tear in return for lower latency and would happen with a fast-enough renderer with triple buffering too. If it swapped at vblank properly to avoid tearing then double buffering won't tear, neither will triple. Triple buffer rendering is about filling in the "I can't render anything now" gap o improve performance (FPS and latency) when some frames sometimes can't fit in the frame budget and go over.