Announcement

Collapse
No announcement yet.

A New Linux OpenGL ABI Is Being Proposed

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

  • #16
    The only right anwser to anything that nvcrap could propose or offer for Linux is: get lost. Far away. The reason for that is that what they are ultimately after is to sneak in their proprietary junk (hardware + software) down people's throat, to shut out any non proprietary alternative. Linus is 100% right about these people.

    Comment


    • #17
      Originally posted by hosh-blot View Post
      will this affect how older games run such as neverwinter nights, quake 4 and what a bout older versions of wine that are needed for games that don't run in the current version?
      too early to say for sure

      Comment


      • #18
        Originally posted by remm View Post
        The only right anwser to anything that nvcrap could propose or offer for Linux is: get lost. Far away. The reason for that is that what they are ultimately after is to sneak in their proprietary junk (hardware + software) down people's throat, to shut out any non proprietary alternative. Linus is 100% right about these people.
        And how does helping mesa co-exist with the nv blob instead forcing one or the other help with proprietary lock-in? What about this proposal do you not agree with, other than the name attached to the poster?

        Comment


        • #19
          Originally posted by remm View Post
          The only right anwser to anything that nvcrap could propose or offer for Linux is: get lost. Far away. The reason for that is that what they are ultimately after is to sneak in their proprietary junk (hardware + software) down people's throat, to shut out any non proprietary alternative. Linus is 100% right about these people.
          probably but on the foss side could be of help too tho, i can fast think the ability to modularize mesa and have a separation between Gallium3d and opengl/GLes versions, for example:

          libGL/EGL.so.1
          -----libGL_mesa_2.so[all opengl up to 2.X maybe using an IR like TGSI/LLVM so is GPU indpendant]
          -----libGL_mesa_3.so[same]
          -----libGL_mesa_4.so[same]
          -----libGLSL_mesa.so[maybe this can be nice to isolate shader processing]
          -----Gallium[convert IR to gpu specific]
          ----r600g
          ----nouveau
          ----intel

          ofc not sure if the exposed by nvidia consider this case and i didn't crosscheck technically this either but well just a fast idea on how could this be useful for mesa

          Comment


          • #20
            Originally posted by RealNC View Post
            This has nothing to do with it. If you eselect another GL library, all applications will use that. You can't have both; eselect simply selects one of several alternatives, it doesn't activate them simultaneously.
            As far as I understand the mailing list message you are wrong. The proposal talks about different libgl's in the file system. Not running simultaniously.

            Gentoo already offers exactly that.

            Comment


            • #21
              Originally posted by energyman View Post
              As far as I understand the mailing list message you are wrong. The proposal talks about different libgl's in the file system. Not running simultaniously.

              Gentoo already offers exactly that.
              As far as I understand it, it can dispatch GL commands based on X screen so you can use different OpenGL implementations simultaneously.

              Comment


              • #22
                Originally posted by energyman View Post
                As far as I understand the mailing list message you are wrong. The proposal talks about different libgl's in the file system. Not running simultaniously.
                I'm not so certain at the moment, though I'm content to wait for XDC to find out. My only resistance would be if this change were to be implemented specifically to address issues with the Nvidia/AMD/PowerVR blobs with no net-gain for Mesa or other FOSS OGL implementations.

                F

                Comment


                • #23
                  Originally posted by elanthis View Post
                  These aren't equivalent. GLUT is like a shitty toy version of GTK/Qt. EGL is an OS-neutral version of GLX. GLUT layers over GLX/WGL/AGL/EGL, and offers borderline useless input and timer mechanisms and window management. EGL lets you create and bind GL contexts to a full real windowing system and allows using the native fully featured window system API for input, timers, I/O, events, etc.
                  thx, i started learning basic GL with GLUT thinking its all the same

                  Comment


                  • #24
                    Originally posted by energyman View Post
                    As far as I understand the mailing list message you are wrong. The proposal talks about different libgl's in the file system. Not running simultaniously.

                    Gentoo already offers exactly that.
                    The message very explicitly states that it should/will support loading multiple vendor back ends in the same address space, in clear terms.

                    And no, Gentoo does NOT allow even having multiple GL implementations simultaneously, because the very infrastructure of Mesa/libGL on Linux does not allow this, hence this entire proposal. Your client application has no way to select a GL implementation at runtime, and the Gentoo (and most every other Linux distro) facilities for swapping GL implementations do so by ripping out the current libGL and replacing it. It does not allow two apps running at the same time using two different libGLs, which is impossible aside from using separate chroot's or LD_PRELOAD tricks (and even then, only when using separate X instances and so on, because X itself can only have a single libGL loaded).

                    Comment


                    • #25
                      Originally posted by elanthis View Post
                      The message very explicitly states that it should/will support loading multiple vendor back ends in the same address space, in clear terms.

                      And no, Gentoo does NOT allow even having multiple GL implementations simultaneously

                      Good answer. The big question that I have is, is this necessary? Are there two OSS GL implementations? If there isn't, then are we not just catering to something that Nvidia desires to facilitate their blobs installation? Does this benefit FOSS GL implementations in any manner, such as being able to run Mesa 8.0 and 9.0 implementations simultaneously, or nouveau and radeon simultaneously, XGL and EGL apps simultaneously?

                      To restate, is this an improvement to Linux, an improvement to Nvidia blob-using-customers, or both?

                      F

                      Comment


                      • #26
                        Originally posted by russofris View Post
                        Good answer. The big question that I have is, is this necessary? Are there two OSS GL implementations? If there isn't, then are we not just catering to something that Nvidia desires to facilitate their blobs installation? Does this benefit FOSS GL implementations in any manner, such as being able to run Mesa 8.0 and 9.0 implementations simultaneously, or nouveau and radeon simultaneously, XGL and EGL apps simultaneously?

                        To restate, is this an improvement to Linux, an improvement to Nvidia blob-using-customers, or both?

                        F
                        seems both as it will help or make easier stuff like optimus/enduro and will make life easier for blobs users

                        Comment


                        • #27
                          Didn't know that using an api with hardware is so limited on linux!

                          We really need some progress on how drivers can expose api's(including abi's), how libraries are handled.

                          And about the file system conflicts. That's why you don't put all the bin of all the user programs in one folder and all the libs of all the user programs in one folder and so on...

                          You give each program it's own folder with subdirectories.
                          One distribution has done this and seems to have found things can work very well:

                          http://www.gobolinux.org/?page=at_a_glance

                          Comment


                          • #28
                            Originally posted by russofris View Post
                            Good answer. The big question that I have is, is this necessary? Are there two OSS GL implementations? If there isn't, then are we not just catering to something that Nvidia desires to facilitate their blobs installation? Does this benefit FOSS GL implementations in any manner, such as being able to run Mesa 8.0 and 9.0 implementations simultaneously, or nouveau and radeon simultaneously, XGL and EGL apps simultaneously?

                            To restate, is this an improvement to Linux, an improvement to Nvidia blob-using-customers, or both?

                            F
                            The proposal goes beyond dynamically-switchable GL implementations. It includes separating GLX from libGL (hooray!) and providing a clean organization for different GL components (EGL, profiles, etc.). I could imagine a lean Mesa implementation for Wayland that completely cuts out GLX while still providing full Desktop GL support. This is not really possible today with the current ABI for libGL.

                            If this also helps NVIDIA to ship a blob that integrates better with the rest of the system, then how is this not a good thing? If anything, this would allow vendors to create hardware-specific, high-performance, open-source GL implementations for their hardware that bypasses Mesa in favor of performance and functionality, and distribute it without having to worry about interfering with system GL libraries. They could expose a GL 4.2 profile without having to first update all of Mesa to be compliant, then implement their driver within the Mesa/Gallium framework. Remember that Mesa is just another OpenGL vendor.

                            Comment


                            • #29
                              Linux OpenGL ABI
                              There is a need to deal with general Linux API ABI's in general. The old system can't do this good enough.

                              Comment


                              • #30
                                Linux (the kernel) has and had stable ABI's and API's for about 20 years - yes as long as its exists.

                                Internal structures are neither API's nor ABI's.

                                Comment

                                Working...
                                X