Announcement

Collapse
No announcement yet.

Wayland Protocols 1.27 Brings Content Type Hinting, Idle Notification

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

  • Wayland Protocols 1.27 Brings Content Type Hinting, Idle Notification

    Phoronix: Wayland Protocols 1.27 Brings Content Type Hinting, Idle Notification

    Wayland-Protocols 1.27 was released this morning by Jonas Ådahl in pushing out two new protocols under the staging umbrella...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    The other new protocol working its way out with Wayland Protocols 1.27 is the ext-idle-notify addition that has been in the works for several years - all the way back to 2015 when started on it by KDE developer Martin Gräßlin.
    So it took 7 years for this simple extension...

    Comment


    • #3
      Code:
          <request name="destroy" type="destructor">
            <description summary="destroy the manager">
              Destroy the manager object. All objects created via this interface
              remain valid.
            </description>
          </request>​
      Based on the description, this one should have been named Karen.

      Comment


      • #4
        There is also finally some activity with the fullscreen tearing protocol for games.

        Btw, no one is really talking about it, but what I really like about x11 is the ability to completely turn off the compositor. (I know KDE, Mate and probably Xfce as well have this ability). When you turn off the compositor, that means maximum amount of VRAM can be reserved for the game, which is important for people like me, who have a 4GB GPU. On Wayland unfortunately, you inherently can't do that because compositing is mandatory and is part of the Wayland design, so that means the compositor will always use a certain amount of VRAM, so less VRAM can be reserved for games.

        Comment


        • #5
          Originally posted by user1 View Post
          so that means the compositor will always use a certain amount of VRAM, so less VRAM can be reserved for games.
          I suppose it should be possible to optimize for this at least a bit with direct scan-out? Xorg itself also consumes a bit of VRAM with KWin compositing disabled.
          But yes, VRAM pressure is not to be underestimated. Especially not with API wrappers, every bit helps.

          Said bit an awful lot, yikes...

          Comment


          • #6
            Originally posted by aufkrawall View Post
            I suppose it should be possible to optimize for this at least a bit with direct scan-out? Xorg itself also consumes a bit of VRAM with KWin compositing disabled.
            But yes, VRAM pressure is not to be underestimated. Especially not with API wrappers, every bit helps.

            Said bit an awful lot, yikes...
            I'm sure some will say 8GB+ VRAM should be the standard now, but there are still new GPU's with 4GB and I'm sure there are cases when APU's also can't access a lot of VRAM. And btw, this may also be the reason why some report their games are running better on Linux than on Windows (because on Windows the compositor is also always running and using at least 200mb of VRAM). I myself ran RAGE 2, (which is a fairly VRAM heavy game) on both WIndows and Linux and got much higher fps on Linux because I ran KDE with the compositor disabled.

            Comment


            • #7
              I guess the compositor could decide to enable the async page flip (tearing) when it receives a content type for game, and the game has vsync disabled. Really looking forward to having that option, I already prefer my gaming experience on Sway over any X WM, even when no compositor is used.

              Comment


              • #8
                Most Vulkan apps run in fullscreen exclusive on Windows with e.g. OS audio volume overlay not visible, so DWM shouldn't steal noteworthy amounts of VRAM. It probably ran faster for you on Linux due to RADV achieving better performance than amdvlk-pro in this title. Perhaps it even managed VRAM pressure better, AMD Windows drivers don't seem to be exactly great in that regard.

                Comment


                • #9
                  I hope 1.28 release will introduce the fractional scale.
                  Last edited by MorrisS.; 11 October 2022, 01:47 PM.

                  Comment


                  • #10
                    Originally posted by aufkrawall View Post
                    Most Vulkan apps run in fullscreen exclusive on Windows with e.g. OS audio volume overlay not visible, so DWM shouldn't steal noteworthy amounts of VRAM. It probably ran faster for you on Linux due to RADV achieving better performance than amdvlk-pro in this title. Perhaps it even managed VRAM pressure better, AMD Windows drivers don't seem to be exactly great in that regard.
                    Well, I tried it more than 2 years ago right after it got released, when RADV didn't even have ACO yet and itself wasn't as optimized as it is today. (Idk, maybe RAGE 2 is an exception, but even today RADV often performs slightly worse than amdvlk-pro in Windows Vulkan games). But my point still stands about the fact that DWM generally can affect performance in games when you're VRAM limited. I've seen someone compared Windows vs Linux performance on an APU with very limited VRAM, and Linux outperformed Windows in every single game.

                    Comment

                    Working...
                    X