Announcement

Collapse
No announcement yet.

KDE On The Importance Of Wayland Explicit Sync

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

  • #11
    Originally posted by Brittle2 View Post

    the issue is because of nvidia
    No, it isn't. That's what Michael claims in the article, but it's not what the blog post says.
    The blog post says implicit sync is mostly guesswork and it guesses wrong often enough that current implementations are effectively explicit sync via a backdoor. Nvidia got it right from the beginning and only supports explicit sync in their driver, but the fact that this change will fit Nvidia's driver is just a bonus. Nvidia wasn't root cause here, Wayland simply did it wrong initially.
    Last edited by bug77; 08 April 2024, 03:47 AM.

    Comment


    • #12
      Originally posted by kokoko3k View Post
      So much wasted manpower to overcome prop. driver problems.

      Wth Nvidia.
      So much manpower wasted to hack around the lack of explicit sync when Vulkan needs it and all other platforms support it.

      Also, EGLStreams were superior to GBM, there is no question about it, Wayland would've been adopted far sooner if the desktops adopted EGLStreams instead of sticking to inferior GBM.

      Comment


      • #13
        Originally posted by mxan View Post

        Also, EGLStreams were superior to GBM, there is no question about it, Wayland would've been adopted far sooner if the desktops adopted EGLStreams instead of sticking to inferior GBM.
        Who said EGLStreams is superior? From this disccusion of some prominent Mesa devs, it doesn't seem so.

        Comment


        • #14
          "With the explicit sync protocol being implemented in compositors and very soon in Xwayland and the proprietary NVidia driver, all those problems will finally be a thing of the past, and the biggest remaining blocker for NVidia users to switch to Wayland will be gone."
          The biggest nVidia-specific blocker for nVidia users, maybe... but I'm an nVidia user and, for me, the biggest blocker will remain insufficient adoption of David Edmundson's patches so things like crash recovery and a Wayland equivalent to kwin --replace can happen. I had to restart my system twice in the last few days due to power outages longer than my UPS capacity, and I'm not a fan of it.

          It's very irritating to have to...
          • ...fire off an xrandr command because KScreen has always been a piece of trash that I turn off for making things worse and something started overruling the MetaModes xorg.conf line somewhere between Kubuntu 16.04 LTS and 20.04 LTS, and the system seems to assign a default monitor layout based on EDID to ensure that just swapping the cables around to default to a virtual order that matches the physical order won't work. (The 16:9 monitor is in the middle between the two 5:4 monitors, dammit!)
            • Funny enough, one of the reasons I was originally looking forward to Wayland was so I wouldn't need to choose between the now non-functional "use MetaModes to lock out resolution changing" approach and writing an LD_PRELOAD hack to keep games from fullscreening and messing up my desktop when they turn off the other monitors.
          • Run the script I wrote to manually launch all the applications I leave open which don't support XSM session restore, then close the "Warning! Someone used Yakuake's D-Bus API to open new tabs!" notification that can't be turned off without killing other, more useful notifications.
          • Run the script I wrote which takes advantage of X11's insecurity and wmctrl to restore all my window positions. (e.g. Firefox's privacy.resistFingerprinting is too coarse-grained and thinks it knows better than session restore, and having one Firefox window per screen means I can't use KWin Rules to match based on window classes. Also useful for resetting to the proper layout when I accidentally move/resize something and, no, I can't just use KWin 6's "tiling", because some of the persisted locations are very distinctly "floating WM" stuff... though being able to script "maximize to left 2/3rds of central monitor" without having to fiddle with pixel dimensions would be nice.)
          • Unlock my password manager to log back into various things which don't support "Remember Me".
          • Close the Pidgin windows for IRC channels that I stay logged into via the contact list.
          • Wait several minutes of 100% on one CPU core for post-3.x versions of BasKet Note Pads to load one of the baskets I use a lot. Rinse-lather-repeat until all are loaded. (If I can ever find the time, I really need to contribute a Flatpak manifest for that thing, then figure out what they broke, fix it, and also fix other things like the messed up tabbing order in the dialog for adding new URL notes.)
          • Remember whether I had any tabs open in Zeal.
          ...plus, occasionally, fight with Plasma because it decides to get the monitors mixed up and I need to swap panels around and drag-and-drop my desktop icons back to the correct monitor. I'd expect this kind of crap in KDE 4.0. By this point, Plasma has just accepted being trash and, if LXPanel supported more than one panel on a single screen edge, I don't think i'd have ever returned from my KDE 3.5 → "LXDE with some KDE apps like K3b and Filelight" switch.
          Last edited by ssokolow; 06 April 2024, 11:26 AM.

          Comment


          • #15
            Excellent progression. When will this advancement be accomplished?

            Comment


            • #16
              Originally posted by user1 View Post

              Who said EGLStreams is superior? From this disccusion of some prominent Mesa devs, it doesn't seem so.
              From what I remember, nVidia support for GBM came about suspiciously soon after nVidia decided "OK, KDE, if that's what it takes, we'll write the EGLStreams backend and give you a developer liason" and said laison was kept very busy running to the nVidia driver team with "How do I do this thing we've already implemented for GBM or plan to implement for GBM?" questions where the answer turned out to be "We never thought anyone would need that, so the architecture doesn't support that".

              (eg. I think David Edmundson's crash recovery patches were one such example. I seem to remember something about EGLStreams's design making it fundamentally impossible to keep allocated GPU resources alive beyond the death of the process that allocated them.)

              Comment


              • #17
                Originally posted by ptr1337 View Post

                If you would have the tweet at a later point I would welcome that.
                According Erik Kurz he told me that the ETA for explicit sync and the 555 Driver will be the 15 May.

                Also he said that the vulkan explicit sync implentation wont be included and this one will come with the 560 ones.

                https://github.com/NVIDIA/egl-waylan...ent-2010292221
                Ahh, it could be Vulkan Explicit Sync then

                Comment


                • #18
                  A great time to let the GBM vs. EGLStreams discussion rest would have been yesterday, as obviously everything is inferior compared to Vulkan with explicit sync that can live without GBM and EGLStreams and (now/soon) also works great with all drivers. No need to be obsessed with the past if future looks bright...

                  Comment


                  • #19
                    Originally posted by hf_139 View Post
                    Tremendous progress, maybe the 15 year old wayland will become usable within the next five years.
                    Yeah. Wayland was ready improving during time as distinct project, but what wasn't ready were drivers, compositors, graphic APIS, and so on. Put a smartphone in the dinosaurs age and thing to what it can be used. Wayland integration has forced to improve the majority of Linux system core. People who complain about Wayland have not understood that the real matter is the reason a specific kind of software doesn't work with wayland yet. Because developers are providing this match in a transition phase. It's not when wayland has been developed, it's when the core is adapted to implement wayland in order to take benefit from it.
                    Last edited by MorrisS.; 06 April 2024, 11:34 AM.

                    Comment


                    • #20
                      I am glad this is getting all resolved. Explicit sync is the main issue that is affecting my day to day usage, but the changes to Xwayland(967) are helping. Many are blaming Nvidia for wayland's slow adoption, but even on AMD hardware Plasma was unstable until Plasma 6 which just came out a couple months ago. Not everyone is going to be happy with using Gnome as the only stable(-ish) mass user implementation.

                      Comment

                      Working...
                      X