Announcement

Collapse
No announcement yet.

Dynamic Triple Buffering Hopefully Will Land For GNOME 44

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

  • smitty3268
    replied
    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?

    Leave a comment:


  • jorgepl
    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 must be joking, right?

    Leave a comment:


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

    Leave a comment:


  • Danny3
    replied
    Does KDE have such a thing?
    It eels pretty slow on Wayland and I was wondering if such a thing could help its performance too.

    Leave a comment:


  • jorgepl
    replied
    Originally posted by mirmirmir View Post
    Honestly, I was fan of this patch, but then, i don't feel any gain in performance with this patch on my pre-ryzen laptop. But yeah, perf optimizations are welcome I guess...
    This is not a performane optimization per se, it just ramps up the frequency of the GPU.

    Leave a comment:


  • lumks
    replied
    Originally posted by mirmirmir View Post
    Honestly, I was fan of this patch, but then, i don't feel any gain in performance with this patch on my pre-ryzen laptop. But yeah, perf optimizations are welcome I guess...
    My problem with this path is that I notice it in worse battery performance. But since I keep my laptop all the time in energy saving mode, where this patch wont do anything, thats OK.

    Leave a comment:


  • lumks
    replied
    Originally posted by royce View Post

    As far as the MR discussion goes the holdup is a key gnome dev that simply doesn't like the approach
    As far as I know the main blocker is simply a lack of time. As this is no simple stand-alone MR, but depends on other MRs before it can be merged:I can't see that there is anyone who don't likes it in a way that there is no chance to merge it. I see that there still is ongoing work and thats a good thing. We want quality where GNOME is happy with the results. keep in mind that GNOME are the ones who will maintain this if Ubuntu pulls the plug and leaves. (Not that this will happen, but in case) TBH I don't see this land in 44.

    Leave a comment:


  • mirmirmir
    replied
    Honestly, I was fan of this patch, but then, i don't feel any gain in performance with this patch on my pre-ryzen laptop. But yeah, perf optimizations are welcome I guess...

    Leave a comment:


  • blacknova
    replied
    I hope they'd finally fix their input layout switcher under X11, since GNOME 42 it become impossible to switch layout in Intelliji IDEA. And annoying and unswitchable layout switch popup have been making my day "brighter" for even longer. I'm no fun of KDE but have been more less forced to switch to it.

    Leave a comment:


  • royce
    replied
    Originally posted by jorgepl View Post
    Why hasn't this been accepted in upstream yet? Is there any particular reason?
    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.

    Leave a comment:

Working...
X