Announcement

Collapse
No announcement yet.

Dynamic Triple Buffering Hopefully Will Land For GNOME 44

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

  • MihaiBojescu
    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.
    While many developers like Rust for its benefits, it sadly is not a magic bullet for each and every performance problem.

    Leave a comment:


  • agd5f
    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?
    At the end of the day, it's the same solution: force the GPU to run at a higher frequency longer. Either by keeping it busy or manually forcing the clocks high longer. Arguably keeping it running slightly longer is more efficient than ramping it up and down several times.

    It's not an easy problem to solve in either software or firmware. The GPU kernel driver doesn't know how big each job is or how long it will take to complete. If it always forced the clocks to ramp to high it would waste power on a lot of workloads that don't need it. Sure you could add a hint that the app could send to the kernel driver to influence it's decision, but then every app would need to be aware of every GPU to determine when it needed the hint or not if you really wanted it to work well across a wide range of GPUs.

    Leave a comment:


  • eagleoneraptor
    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.
    Jokes aside, is the sentence "They should just rewrite Mutter and make a new one on top of wlroots" also a joke? Because I don't really know for certain.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by AnAccount View Post
    Threre are other projects like Cosmic that are implementing compositors in rust which seems to do just find, but from what I understand they do not wrap wlroots.
    and it does do pretty well, it uses smithay, which is the wlroots equivalent, its not super featureful but its good enough for a basic desktop, I've used anvil (kinda like the weston of smithay) as well as cosmic, and so far cosmic is actually not too bad if you can discount the crashing once every 20 minutes or so, but to be completely fair, I build the git versions of all the packages linked in cosmic-epoch, so thats really not a fair comparison. however for a stacking/tiling combo compositor, so far it looks and feels really promising, fun to dink around with, but afaik they arent even at the stage were they are taking user error reports

    Leave a comment:


  • kpedersen
    replied
    Originally posted by AnAccount View Post
    Disclaimer: The actual speed was not the issue here
    Speed doesn't matter; I clearly stated it was the work involved in creating the bindings against C that was the issue.

    Originally posted by AnAccount View Post
    But, remember the rust suggestion was a joke in the first place....
    Rust suggestions are always a joke aren't they?

    Originally posted by Quackdoc View Post

    considering they gave up on the C one too, not convinced.
    Heh, fair; but they did mention in a blog that the project was abandoned for a different reason rather than language. This is more due to the scope required in creating a Wayland compositor in general. Relating to why the Wayland ecosystem will always have very little choice of standalone compositors compared to X11 WMs.
    Last edited by kpedersen; 10 January 2023, 07:42 AM.

    Leave a comment:


  • AnAccount
    replied
    Originally posted by kpedersen View Post

    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
    Disclaimer: The actual speed was not the issue here, the original comment mentioning rust was a joke. Also, using rust would also most likely not give any performance improvements, but as I said that was not the issue in the first place. So, this is really a side track not related to the issue.

    So, with the disclamer out of the way, from what I see the Way Cooler was wrapping wlroots C api, to use with rust. And then, you will get an overhead. There are tools to assist with this, like bindgen, but you will still have to work with the C api to some extent wrapping it in unsafe and do type conversion aso. It might still be worth it from a reliability point of view, but it is not without a cost. Threre are other projects like Cosmic that are implementing compositors in rust which seems to do just find, but from what I understand they do not wrap wlroots. But, remember the rust suggestion was a joke in the first place....

    Leave a comment:


  • jorgepl
    replied
    Originally posted by treba View Post

    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".



    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.
    Very interesting insight on the iOS topic.

    Precisely because iOS should have the best drivers out there, given the platform writers are also the driver writers. I wonder if iOS had triple buffering since v1 and that's why it was smoother than the competition back then.

    Leave a comment:


  • xAlt7x
    replied
    Originally posted by Linuxxx View Post

    FWIW, the Wayland desktop of Ubuntu 22.04 LTS performs without a single hiccup on my discrete AMD Radeon R9 380 GPU.
    Unfortunately that's not the case for me with AMD Lucienne (Zen 2 mobile integrated GPU). Hovewer env variable MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0​ / MUTTER_DEBUG_FORCE_KMS_MODE=simple​ (as mentioned in Daniel Van Vugt blog post) helps with sluttering.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by kpedersen View Post

    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
    considering they gave up on the C one too, not convinced, smithay and cosmic seem to be progressing perfectly fine.

    Leave a comment:


  • clapbr
    replied
    Originally posted by xAlt7x View Post
    Yeah. Good old KWIN_TRIPLE_BUFFER variable is still available.
    never had good results with this hack on any AMD/NVIDIA GPU, always makes the things you try to fix worse even with Triple Buffer forced on driver also.
    When vsync was shit years ago with amdgpu it didnt help at all also, and no hacks been necessary with that for a couple of years already.
    Frame timings start going crazy with a couple of windows rendering at different rates.

    Leave a comment:

Working...
X