Announcement

Collapse
No announcement yet.

Two Features Wayland Will Have That X Doesn't

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

  • #16
    I don't think any open source 3d stack will be able to come even remotely close to the performance of the proprietary drivers, so unless Wayland is thinking of supporting an alternate rendering path not based on KMS and GEM (the KMS symbols are GPL'ed and therefore cannot legally be used by Nvidia/ATI binary drivers no matter how badly they want to use them), there will be no meaningful gaming on Wayland. Maybe the best of the best open source drivers may be able to run a native port of OpenArena to Wayland in 2015. But something with actual fragment shaders? Forget it.

    Comment


    • #17
      X.org is only still useful for the internet. An AMD 6800 has a 1GB framebuffer, for which you won't use all of it (not even 1/30) and with a GB LAN port and cables, this is totally neglect-able. You can simply transfer the raw framebuffer image over a gigabyte ethernet cable.

      X.org was only invented for LAN anyway.

      Wayland solves all problems with X.org, namely the fact that it starts from scratch 20 years later. X.org may be perfectly fine, but the effort and thus time it takes for it to transform to something modern, while staying in a working state with the nVidia blob, is just realy big.

      Letting X.org bitrot for the blobs and having Wayland for the FLOSS drivers is just epic.

      And let's face it; you directly use the Xserver all the time anyway, and partly the client when on remote.

      That's 100% of the time slower than Wayland and 100%>time speedup.
      Wayland is 100% of the time faster than X.org on the client side and 100%>time slowdown on remote.

      Logical breakdown?

      Comment


      • #18
        @allquixotic

        Actual fragment shaders? What do you think OA's bloom effect uses?

        Comment


        • #19
          Originally posted by V!NCENT View Post
          X.org is only still useful for the internet. An AMD 6800 has a 1GB framebuffer, for which you won't use all of it (not even 1/30) and with a GB LAN port and cables, this is totally neglect-able. You can simply transfer the raw framebuffer image over a gigabyte ethernet cable.

          X.org was only invented for LAN anyway.

          Wayland solves all problems with X.org, namely the fact that it starts from scratch 20 years later. X.org may be perfectly fine, but the effort and thus time it takes for it to transform to something modern, while staying in a working state with the nVidia blob, is just realy big.

          Letting X.org bitrot for the blobs and having Wayland for the FLOSS drivers is just epic.

          And let's face it; you directly use the Xserver all the time anyway, and partly the client when on remote.

          That's 100% of the time slower than Wayland and 100%>time speedup.
          Wayland is 100% of the time faster than X.org on the client side and 100%>time slowdown on remote.

          Logical breakdown?
          There is no reason to believe that Wayland will be better because the code is newer. There is no reason to believe that Wayland will perform better because it doesn't contain network pathways.

          Wayland is largely vaporware right now. It doesn't exist in a way that can be compared to Xorg.

          ************************************
          Let's think pragmatically for a minute. The main appeal of Wayland seems to be for performance reasons. Let's assume that Wayland does have a reasonable performance benefit, which I find highly doubtful. As allquixotic points out, proprietary drivers won't be able to use Wayland without major changes. Therefore, open source graphics drivers are a requirement for Wayland. But by using open source drivers, you're sacrificing way more performance than Xorg ever caused. People that care about performance -- like gamers -- will continue to use Xorg + fglrx V nvidia.
          I do believe that the open source drivers will aggressively develop new features and improve stability, but they won't be able to match the performance of the proprietary drivers, ever.
          That really leaves us with the question of who cares about Wayland. People that care about a fully open source system will, but I doubt that they care about performance anyways.
          Wayland isn't a pragmatic approach in any category, but then again, FOSS supports don't tend to be pragmatic...

          Comment


          • #20
            Originally posted by jbrown96 View Post
            There is no reason to believe that Wayland will be better because the code is newer. There is no reason to believe that Wayland will perform better because it doesn't contain network pathways.

            Wayland is largely vaporware right now. It doesn't exist in a way that can be compared to Xorg.

            ************************************
            Let's think pragmatically for a minute. The main appeal of Wayland seems to be for performance reasons. Let's assume that Wayland does have a reasonable performance benefit, which I find highly doubtful. As allquixotic points out, proprietary drivers won't be able to use Wayland without major changes. Therefore, open source graphics drivers are a requirement for Wayland. But by using open source drivers, you're sacrificing way more performance than Xorg ever caused. People that care about performance -- like gamers -- will continue to use Xorg + fglrx V nvidia.
            I do believe that the open source drivers will aggressively develop new features and improve stability, but they won't be able to match the performance of the proprietary drivers, ever.
            That really leaves us with the question of who cares about Wayland. People that care about a fully open source system will, but I doubt that they care about performance anyways.
            Wayland isn't a pragmatic approach in any category, but then again, FOSS supports don't tend to be pragmatic...
            Why want open source drivers not match proprietary driver... eventually?

            Comment


            • #21
              Originally posted by bac0n View Post
              Why want open source drivers not match proprietary driver... eventually?
              Because the proprietary drivers have better teams (better programmers and more of them) developing them. Open source driver performance has not been improving at a respectable rate. It's not like the proprietary graphics drivers won't also improve, and the open source drivers aren't improving faster than the proprietary ones.

              The real problem with graphics on Linux is that no one that matters cares. If Red Hat's, Novell's, Oracle's, HP's, etc. business depended on great open source Linux graphics drivers, then Wayland and associated drivers would have a really good chance. However, it's not a priority. How many man-hours do you think have been spent on the Nvidia or AMD graphics stack? Both of those companies claim that the super-majority of their code is shared between Windows and Linux. I'd say that they've spent $100M on the development.
              I just can't believe that G3D/Mesa will get any reasonable amount of development time.
              A project like this simply can't be done as a volunteer project. It's too complicated to attract casual developers and insignificant to attract major business investment.

              Comment


              • #22
                Originally posted by bac0n View Post
                Why want(sic) open source drivers not match proprietary driver... eventually?
                It's probably because of lack of manpower, but the open-source drivers should eventually have 60-70% of the proprietary driver performance.

                Comment


                • #23
                  X is a very complex beast, I don't think there are many people out there who have a full understanding of it. What I'm hoping and thinking Wayland will bring is.
                  • A simplified architecture without all the legacy stuff allowing more people to understand it and contribute to it, and reduced risk that modifications will break legacy stuff and god knows what.
                  • No more need for ddx, means less duplication of code, all hardware specific code in Gallium driver and drm. Development effort concentrated on Gallium driver.
                  • No more need for exa, all 2D optimizations concentrated in cairo library with the gl backend, hopefully making it easier to bring better 2D performance with Firefox etc.

                  Comment


                  • #24
                    I just saw this comment by a NVidia developer in the NVidia forums:

                    One thing worth noting is that beside the small footprint the Wayland display server may have at this time and the relatively early stages of development it is in, there are architectural limitations to its design that present problems for features that are taken for granted today.

                    Although it is quite old now, a good part of the discussion of using X-on-OpenGL vs. X.Org for composited desktops in Andy Ritger's presentation for the 2006 X developers' conference applies to Wayland, as well:

                    http://download.nvidia.com/developer...-framework.pdf
                    (emphasis mine)

                    If anybody could elaborate on that please do so.

                    Comment


                    • #25
                      Originally posted by allquixotic View Post
                      I don't think any open source 3d stack will be able to come even remotely close to the performance of the proprietary drivers, so unless Wayland is thinking of supporting an alternate rendering path not based on KMS and GEM (the KMS symbols are GPL'ed and therefore cannot legally be used by Nvidia/ATI binary drivers no matter how badly they want to use them), there will be no meaningful gaming on Wayland. Maybe the best of the best open source drivers may be able to run a native port of OpenArena to Wayland in 2015. But something with actual fragment shaders? Forget it.
                      There is a misunderstanding here, wayland doesn't strictly need KMS/GEM. Wayland can easily use some others interface to setup video mode and to share buffer. What wayland needs is an EGL driver and modesetting capabilities without X, then if the EGL implementation has the EGL image extension it all should work properly ie all you need is to change bit of wayland that is not exposed to its client to work on somethings else than KMS.

                      Comment


                      • #26
                        Wayland doesn't have the Window resizing hell, which is highly noticable. I know nVidia is out tofix this in X.org with sync fences, but only God knows what kind of performance hell this will turn into.

                        Wayland will rock because it is essentialy new X.org tech without the legacy code. Read that again.

                        Also I use Linux because of the FLOSS, otherwise I would run Windows 7/Mac OS X 10.6. Why would I use a sub optimal FLOSS computer with an optimal graphics binary? There are other reasons than ideology to use FLOSS. Mine is curiosity and choice.

                        Comment


                        • #27
                          Originally posted by DeiF View Post
                          I just saw this comment by a NVidia developer in the NVidia forums:

                          (emphasis mine)

                          If anybody could elaborate on that please do so.
                          this

                          anybody know what the Nvidia guy means???

                          Comment


                          • #28
                            Would like to know this as well...

                            Comment


                            • #29
                              Originally posted by kuse View Post
                              There are two kinds of people in the world, pessimist's and optimist's
                              You mean 10 kinds? ... sorry couldn’t resist.

                              Comment


                              • #30
                                Are we talking qubits or hex when we say 2?

                                Comment

                                Working...
                                X