Announcement

Collapse
No announcement yet.

Clear Linux Exploring "libSuperX11" As Newest Optimization Effort

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

  • #11
    Good to see that they haven't run out of ideas to optimize the Linux desktop yet.

    Comment


    • #12
      I'm all for optimizations and improvements, but this sounds like an awful lot of work for little to no benefit, especially considering that applications need to add support for it. I can't imagine the benefits being noticeable from this, but I might be missing something. If I'm wrong, I'll happily congratulate them though

      It would be really interesting if they did some benchmarks, comparing the same application on regular X11 vs this approach to give an idea of what to expect.

      Comment


      • #13
        If that does give a noticeable benefit, imagine the possibilities of a libSuperGUI that includes all the X libraries and Qt and GTK etc.!

        Comment


        • #14
          Originally posted by AnonymousCoward View Post
          If that does give a noticeable benefit, imagine the possibilities of a libSuperGUI that includes all the X libraries and Qt and GTK etc.!
          Why limit to GUIs? libSystemd including all and every .so file!

          Comment


          • #15
            Ostensibly you could just symlink all of them, and it would magically resolve itself.

            Comment


            • #16
              I think it would be interesting to link Mesa directly into some applications, LTO could have a pretty big impact then (though last time I tried to static link accelerated Mesa, I didn't manage to get it working); you could probably eliminate most of Mesa at link time for most applications, and PGO would also be a lot more meaningful. Another option might be to link an OpenGL-on-Vulkan implementation if an efficient one ever comes along, and in that case you could author the OpenGL implementation to be easy to inline.

              Comment


              • #17
                Originally posted by microcode View Post
                Another option might be to link an OpenGL-on-Vulkan implementation if an efficient one ever comes along, and in that case you could author the OpenGL implementation to be easy to inline.
                If you're really performance-minded, then I'd imagine you'd do better with a more modern and streamlined library atop Vulkan than OpenGL.

                I'm waiting for the dust to settle in the realm of Vulkan wrappers. Once there are a handful of popular ones, I'll look at them more seriously. I doubt I'll miss OpenGL.

                Comment


                • #18
                  Michael, the article is wrong about (at least) one thing: These libraries were separate from the beginning, long before X.org or modularization happened.

                  Comment


                  • #19
                    what an awful idea.

                    Comment


                    • #20
                      I wouldn't oppose it, at least not yet.

                      Plain linked libraries are not really modular anyway, they're not like an OS's utilities, so it really is just a change to how the code is delivered. The only concern would be if consolidation cut flexibility for the distributions, if they plan to give the lib a solid build and configuration system, I'd think it would be a positive move.

                      However you guys need to get off Intel's nuts, they make lots of code for sure, but they have a history of making code unusable for any other project or goal than their own. Also no shared wins means Linux dies, it's a classic tragedy of the commons.

                      AMD and Valve deserve props, far more than Intel.


                      Last edited by techzilla; 07 January 2019, 11:43 AM.

                      Comment

                      Working...
                      X