Announcement

Collapse
No announcement yet.

KDE Plasma 5.12 Pushing For "An Awesome Release On Wayland"

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

  • #51
    Let's make KDE great again?

    Comment


    • #52
      Originally posted by bug77 View Post

      Not only am I unable to spot these drops, but I have enabled the FPS counter (in addition to all the effects I usually have turned on), played with the open windows in any way that crossed my mind and the counter never dipped below 60fps. On a mobile and ancient 610M.
      Nice for you and your mobile and ancient 610M, which I absolutely don't care about as a GTX 1070 owner. Maybe get some recent hardware before always telling "everything's fine" over and over again?

      Comment


      • #53
        Meanwhile, radeon users rejoice.

        Comment


        • #54
          Originally posted by darclide View Post
          As long as Plasma / Kwin do not support nvidia with Wayland, at least the category "gamers" will not use it, also likely most people who have to do 3d / OpenGL / Vulkan stuff, where MESA is simply not even remotely on par with the nvidia blob. So developers affected by these won't help.

          Distributions likely also don't feel like helping, Gnome works with Wayland on all graphic cards and drivers, so for distributions going with Gnome instead of KDE Plasma is a more safe decision.

          And by that, given developers and distributions have sane reasons to not choose Wayland & Plasma, it will also not arrive for users.

          This is a shame and should be fixed, people should be way more pragmatic and not block a product for ideological reasons.
          The problem you're having is not with plasma or mesa or wayland, it's with your choice of hardware. What you're doing is just like blaming some god for a rain storm, when the real solution is to move to a sunnier location.

          Comment


          • #55
            Originally posted by jrch2k8 View Post
            Theoretical shortcomings that EGLStreams neither fully fix nor provide any worth while enhancement outside the fact the only driver on the planet that supports it is nVidia(and maybe some obscure ARM/MIPS blob).
            Well, EGLStreams is all about format negotiation, looks like it is can be useful besides wayland surfaces allocation. Some VNC solutions for example. Maybe other drivers should implement this extension? For me, it looks like better solution than just make yet another API used exclusively within wayland display manager.
            Originally posted by jrch2k8 View Post
            I do agree on the fact there is room for improvement and they should work together on a implementation that fix both shortcomings
            For me it looks like NIH syndrome. Lets invent some other API just not to use something that nvidia suggested!

            Comment


            • #56
              Originally posted by Khrundel View Post
              Well, EGLStreams is all about format negotiation, looks like it is can be useful besides wayland surfaces allocation. Some VNC solutions for example. Maybe other drivers should implement this extension? For me, it looks like better solution than just make yet another API used exclusively within wayland display manager.
              For me it looks like NIH syndrome. Lets invent some other API just not to use something that nvidia suggested!
              GBM is used on everything in the open stack and then wayland also GBM(maybe not as detailed but is there and works) allow negotiation too and remember Weston has RDP support which is like VNC, so it is already perfectly possible that kwin and mutter don't implement their own is another unrelated story

              if nVidia suggested it 5 years ago fine, but after GBM was finalized and adopted by every driver under the sun then suddenly nVidia drop out of nowhere a driver with EGLStreams without any consultation or previous warning, they are the ones with NIH syndrome not mesa since they are the ones 5 years late to the party.

              Adopt EGLStreams now means changing every driver(R600g, RadeonSI, VC4, VC5, etnaviv, Intel, Freedreno, etc.) and EGLStream also have a lot of weak points, that is why Mesa(as all other contributors) and nVidia are looking for a jack of all trades solution to avoid rewrite half mesa twice

              Comment


              • #57
                Originally posted by jrch2k8 View Post
                GBM is used on everything in the open stack
                X11 is used too. Sometimes a thing is used just because nobody strong enough to replace it with something better.
                Originally posted by jrch2k8 View Post
                and remember Weston has RDP support which is like VNC, so it is already perfectly possible that kwin and mutter don't implement their own is another unrelated story
                "Has support" doesn't mean "good at it". For example Xv can render video, but doesn't support hardware decoding.
                Originally posted by jrch2k8 View Post
                if nVidia suggested it 5 years ago fine, but after GBM was finalized and adopted by every driver
                Who finalized GBM? This is just "proprietary" MESA thing, used within weston because it was only way to allocate buffers available on developer's machines.
                As far as I understand, wayland is nothing to do with GBM. Wayland actually designed to be as minimal and agnostic as possible. Most of the X11 functions are impossible to implement using just wayland, it was designed so. You want screenshots/screencasting/keyboard language switcher or just touchpad edge scroll? Use compositor's builtin or some kind of DE extenstion. Weston uses GBM, Mutter uses GBM or EGLStreams, and both are wayland compatible.
                Originally posted by jrch2k8 View Post
                Adopt EGLStreams now means changing every driver(R600g, RadeonSI, VC4, VC5, etnaviv, Intel, Freedreno, etc.) and EGLStream also have a lot of weak points, that is why Mesa(as all other contributors) and nVidia are looking for a jack of all trades solution to avoid rewrite half mesa twice
                EGLStreams is just another EGL extension. You don't have to rewrite half of MESA to implement one interface, which tells something like "hey, I support GBM-like buffers only". I don't know why they are inventing another solution, maybe because EGLStreams in current implementation lacks comething useful (Martin have written something like that) or maybe it just too complicated to implement it within every wayland composer fully.

                Comment


                • #58
                  Are you joking? Do you really think that there are many users game on Linux? who game using Windows.
                  A Gnu / Linux user should not have Nvidia hardware! Nvidia is a proprietary shit and you have to shout it and no longer buy Nvidia scrap!

                  Comment


                  • #59
                    Originally posted by Khrundel View Post
                    X11 is used too. Sometimes a thing is used just because nobody strong enough to replace it with something better.
                    "Has support" doesn't mean "good at it". For example Xv can render video, but doesn't support hardware decoding.
                    Who finalized GBM? This is just "proprietary" MESA thing, used within weston because it was only way to allocate buffers available on developer's machines.
                    As far as I understand, wayland is nothing to do with GBM. Wayland actually designed to be as minimal and agnostic as possible. Most of the X11 functions are impossible to implement using just wayland, it was designed so. You want screenshots/screencasting/keyboard language switcher or just touchpad edge scroll? Use compositor's builtin or some kind of DE extenstion. Weston uses GBM, Mutter uses GBM or EGLStreams, and both are wayland compatible.
                    EGLStreams is just another EGL extension. You don't have to rewrite half of MESA to implement one interface, which tells something like "hey, I support GBM-like buffers only". I don't know why they are inventing another solution, maybe because EGLStreams in current implementation lacks comething useful (Martin have written something like that) or maybe it just too complicated to implement it within every wayland composer fully.
                    1.) you said " yet another API used exclusively within wayland", I was just clarifying is used everywhere on the open stack

                    2.) As far as I know EGLStream theoretically could be more efficient at but as far as implementations go there is none to compare with Weston, so right now no one knows if EGLStream will perform any better than GBM on those scenarios, hence this is moot. My point simply is "it works" since your wording on the matter implied that it couldn't as it is.

                    3.) Who finalized GBM? Mesa which translate into community + AMD + Intel + ARM providers(an linaro community) which probably account for more than +80% of all GPU used on Linux vs EGLStream that probably even Khronos didn't expect anyone to implement it ever and I mean probably the only existing implementation in use is the one from nVidia.

                    4.) Wayland is a protocol, you are right in the sense it does not depend too much on any underlaying implementation but the drivers do, the problem here with GBM vs EGLStreams is driver side implementation then compositor side support, is a lot of work and again no one has proved with actual DATA that EGLStream provide any benefit that justify such and undertaking outside wishful thinking and API theories(that again both sides have a bunch of pros and cons and neither do all properly--accepted by actual mesa and nVidia developers alike)

                    5.) yes, "EGLStreams is just another EGL extension" but sadly the real world is not so forgiving and those buffers mapped by either GBM or EGLStreams will need translation layers because the drivers themselves use GBM while a theoretical EGLStream compositor will map their buffer using EGLStreams and the binding is different enough. In the best case scenario Mesa would need an higher level buffer management code that either map buffers on GBM or with EGLStream at runtime to keep things sane enough and probably certain kernel drivers will need "fixes" to support EGLstreams bindings properly but I'm unsure here how extensive that could end up being. I guess each driver developer will explain what will change if that ever happens.

                    Comment


                    • #60
                      Originally posted by aufkrawall View Post
                      Nice for you and your mobile and ancient 610M, which I absolutely don't care about as a GTX 1070 owner. Maybe get some recent hardware before always telling "everything's fine" over and over again?
                      Are you seriously telling me my 610M outperforms your 1070? If so, then your problem isn't Nvidia. It lies somewhere else.

                      There, I think I fed you enough, I'm going to stop here and now.

                      Comment

                      Working...
                      X