Announcement

Collapse
No announcement yet.

Dynamic Triple Buffering Hopefully Will Land For GNOME 44

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

  • Anvil
    replied
    Originally posted by MastaG View Post
    They should just rewrite the core components like Mutter in rust.
    Then it would be fast enough by itself without the need for a triple buffer.
    Rust is a Pile of Poo

    Leave a comment:


  • Linuxxx
    replied
    Originally posted by smitty3268 View Post
    Can someone again explain why this is the proper way to fix this issue, rather than fixing the underlying GPU driver issues causing it to not ramp up clocks fast enough?

    Even just adding some kind of desktop mode or sensitive hint in order to force the driver to ramp clocks more quickly than their current algorithm seems like it'd be less of a hack.

    Or have the desktop devs just given up on the kernel devs ever fixing the drivers?
    AFAIK, there's not much the kernel devs can do about the dynamic reclocking of GPUs, because it's all handled by the locked down firmware.

    Leave a comment:


  • Linuxxx
    replied
    Originally posted by mirmirmir View Post

    That raises a question. Does this patch only affect Intel gpu? Can anyone confirm any benefits on non-Intel devices?
    FWIW, the Wayland desktop of Ubuntu 22.04 LTS performs without a single hiccup on my discrete AMD Radeon R9 380 GPU.

    Leave a comment:


  • xAlt7x
    replied
    Originally posted by Danny3 View Post
    Does KDE have such a thing?
    Yeah. Good old KWIN_TRIPLE_BUFFER variable is still available.

    Leave a comment:


  • treba
    replied
    Originally posted by royce View Post

    The changes have been in Ubuntu for at least a year, and it being the most used desktop distribution I would imagine any real issues have long been found and ironed out. As far as the MR discussion goes the holdup is a key gnome dev that simply doesn't like the approach. Stark contrast between doers and chin-strokers.
    Short reminder that the key gnome dev in question is one of the main "doers" and just asks for things to be done properly so they don't get in the way. Similar to how kernel devs don't take in every patch that is carried downstream somewhere "because it works".

    Originally posted by sarmad View Post
    Any Mutter dev hear to comment on how mutter internally does the rendering? I remember some time ago doing a simple test and realizing that Mutter seems to be copying all the windows regardless of whether they are hidden by other windows, i.e just copying all windows to the display buffer back to front without doing any clipping to save unneeded pixel copies. I tried doing the test again on Ubuntu 22.04 but don't clearly see the same issue and I'm not sure whether that's just a side effect of this triple buffering.

    The test I did was simple: put a lot of windows all in full screen mode, then film the screen with a fast camera (slow mo video) while doing the activities animation. What I noticed at the time was that the animation starts choppy and as the windows get smaller the animation becomes less choppy and eventually becomes smooth. The reverse also happens. I.e. in the activities close animation the animation starts smooth and becomes choppy as the windows become bigger even though they start covering each other. If clipping was done then the amount of pixels copied would remain roughly the size of the frame buffer and hence performance shouldn't degrade as the windows become bigger.
    What you're describing is correct for animations - so called "culling" is not done in that case (but is done during "normal" usage). There's a WIP branch fixing that though: https://gitlab.gnome.org/GNOME/mutte..._requests/1497

    That's however in most cases not the reason why the animation like the one to the overview is not smooth. The problem there is actually how most drivers decide when to ramp up the clocks, as apparently most other platforms, including e.g. iOS or Android, are using triple-buffering in a similar way as proposed by Daniel.

    Leave a comment:


  • sarmad
    replied
    Any Mutter dev hear to comment on how mutter internally does the rendering? I remember some time ago doing a simple test and realizing that Mutter seems to be copying all the windows regardless of whether they are hidden by other windows, i.e just copying all windows to the display buffer back to front without doing any clipping to save unneeded pixel copies. I tried doing the test again on Ubuntu 22.04 but don't clearly see the same issue and I'm not sure whether that's just a side effect of this triple buffering.

    The test I did was simple: put a lot of windows all in full screen mode, then film the screen with a fast camera (slow mo video) while doing the activities animation. What I noticed at the time was that the animation starts choppy and as the windows get smaller the animation becomes less choppy and eventually becomes smooth. The reverse also happens. I.e. in the activities close animation the animation starts smooth and becomes choppy as the windows become bigger even though they start covering each other. If clipping was done then the amount of pixels copied would remain roughly the size of the frame buffer and hence performance shouldn't degrade as the windows become bigger.

    Leave a comment:


  • sarmad
    replied
    Originally posted by MastaG View Post
    They should just rewrite the core components like Mutter in rust.
    Then it would be fast enough by itself without the need for a triple buffer.
    You forgot to add /s

    Leave a comment:


  • MastaG
    replied
    Originally posted by jorgepl View Post

    You must be joking, right?
    I am indeed.
    Having no experience with rust at all, I just like to make the "Rust beats everything"-quote every now and then.

    Leave a comment:


  • mirmirmir
    replied
    Originally posted by smitty3268 View Post
    Can someone again explain why this is the proper way to fix this issue, rather than fixing the underlying GPU driver issues causing it to not ramp up clocks fast enough?

    Even just adding some kind of desktop mode or sensitive hint in order to force the driver to ramp clocks more quickly than their current algorithm seems like it'd be less of a hack.

    Or have the desktop devs just given up on the kernel devs ever fixing the drivers?
    That raises a question. Does this patch only affect Intel gpu? Can anyone confirm any benefits on non-Intel devices?

    Leave a comment:


  • kpedersen
    replied
    Originally posted by MastaG View Post
    They should just rewrite the core components like Mutter in rust.
    This is a good hands on article on why Rust is a pain in the arse for this kind of task and why people like to talk about Rust more than actually using it.

    Giving up on wlroots-rs (way-cooler.org)‚Äč

    It all boils down to bindings against underlying C. Bindgen and swig are only viable solutions for people who haven't actually tried using them
    Last edited by kpedersen; 09 January 2023, 04:15 PM.

    Leave a comment:

Working...
X