Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • raster
    replied
    Originally posted by Ipkh View Post
    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.

    Leave a comment:


  • libcg_
    replied
    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.

    Leave a comment:


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

    Leave a comment:


  • leipero
    replied
    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.

    Leave a comment:


  • Aryma
    replied
    imagine you need 1080ti to run your desktop environment

    Leave a comment:


  • indepe
    replied
    Originally posted by Ipkh View Post
    Modern systems don't do this and just repeat the current frame when Vsync is in play.
    When work has piled up, there is no question of repeating a frame. It is the opposite problem, and none of tearing only. It doesn't occur in games in the same way because for a fps game, piled up work is outdated and not of any interest anymore.

    I agree with you that there is a question of why that much work piles up in the first place, for a desktop. It probably also has to do with the general structure of Gnome's rendering, which might connect more work to each buffer than necessary, but that I wouldn't know. If so, it would probably be much more difficult to change (if even practically possible).

    EDIT: You seem to also imply that rendering should simply wait with swapping until the frame is completely done. But that would increase latency for those parts that are ready to be displayed (perhaps the contents of a window with high frame rate). That's what you might do within an application, but this might involve coordinating the output from multiple applications.
    Last edited by indepe; 07 September 2020, 04:53 PM.

    Leave a comment:


  • Ipkh
    replied
    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.

    Leave a comment:


  • libcg_
    replied
    Originally posted by indepe View Post
    If he found a way to do this without reducing latency when there is no piling up of work, then it is a great feature and not (or not just) a driver-specific trick.
    Yes, the proposed MR falls back to double buffering to lower latency in the common case. Android does that since Jelly Bean.

    Leave a comment:


  • indepe
    replied
    Gnome is not like a game that simulates events in time. As I understand it, if work piles up, triple buffering works around the gap of inactivity that would occur when the first buffer is displayed, the second buffer has been made ready to be displayed, but the first buffer isn't released yet for the following frame. Then the third buffer can be used to continue work while the first one is still on screen (and the second one already completed).

    If he found a way to do this without reducing latency when there is no piling up of work, then it is a great feature and not (or not just) a driver-specific trick.

    I'm saying that without having close knowledge of this, but the advantages and disadvantages of user level options for video game configuration should not be confused with the advantages and disadvantages of low level implementation possibilities (which are able to change or mitigate any user level effects known in common video games).

    Leave a comment:


  • Ipkh
    replied
    Wrong. The problem with double buffering is that when the vsync interval is missed, the GPU will stay idle for the next interval, which generates a negative feedback loop by forcing the driver to ramp frequency _down_ and increasing the chances of missing the vsync interval after that.
    That makes almost no sense at all. Logically if the remder pipeline misses the gsync interval the hardware is/was still rendering the frame. The original buffer get sent until it gets replaced. Triple buffering adds more workload on the rendering pipeline in high COU and GPU and Memory for the extra frame. Not to mention an extra frame of latency.
    This is not helpful for battery or system responsiveness and should not get merged.
    The fix is to find why the frame got missed. Desktop should not be changing much and an idle desktop should be repeating tons of frames. Missing a specific refresh interval shouldn't matter that much. Tightening up the UI code would because better use of resources.

    Leave a comment:

Working...
X