Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 30

Thread: A New Linux OpenGL ABI Is Being Proposed

  1. #11
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Also, the implication of this proposal are very clear and easy to understand.

    A) no more replacing libGL.1.so to switch drivers. Core OS-provided libraries should never be replaced with addon libraries.

    B) vendor libraries are separate, so you can install AMD and NVIDIA drivers simultaneously, without requiring distro-specific selection mechanisms.

    C) the GL API is bound in the vendor-neutral OS-provided library, so you can load multiple drivers into the same address space. This means you can draw with a discrete NVIDIA GPU while offloading other work to your integrated Bulldozer or Intel GPU.

    D) vendors will be able to opt out of providing the deprecated non-Core profile functions, e.g. as Apple does, which simplifies drivers and can even allow some mild performance improvements (though we'd need another round of GL function removals and DSA additions to get any significant improvements).

    E) the APIs for device management in the window system are provided by the OS primarily with driver extensions, so proprietary drivers could work with Wayland or any other future new display system that uses GL/EGL, while GLX can be phased out.

    F) allows the removal of cruft that will not be needed in the future, like GLX, which right now must be implemented by the drivers, even for systems that don't use X at all.
    Last edited by elanthis; 09-13-2012 at 02:49 PM.

  2. #12
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    964

    Default

    Quote Originally Posted by mdias View Post
    I don't really know where you guys got the impression that this benefits developers only. The article clearly states that it's a benefit for software vendors and users.

    It will benefit users in being possible for multiple 3D drivers to coexist in the same filesystem. I can imagine for instance having the intel opensource stack coexisting with fglrx and being able to select the default driver to use for applications. Meaning I can select which GPU I want to run an application on.
    You should also be able to have both nVidia hardware and AMD hardware in the same machine and select which app runs on which GPU.
    This could work with Optimus for example, with the nvidia blob and the Intel driver coexisting peacefully on the same system and sharing their buffers seamlessly. Another scenario would be a multihead setup with say an AMD card alongside an nvidia one and each one is driven by their respective blobs

  3. #13
    Join Date
    Jan 2009
    Posts
    466

    Default

    Quote Originally Posted by elanthis View Post
    Also, the implication of this proposal are very clear and easy to understand.
    ..good answers...
    I guess that I'm OK with this. The "why are we doing this" is fairly important to me. I just want to be certain that this will be helping us in the case of wanting to load two FOSS drivers. I want to be certain that we're doing this to prevent blobs from interfering with mesa, and not solely to benefit vendors who choose not to take part in the FOSS ecosystem.

    F

  4. #14
    Join Date
    Jun 2009
    Posts
    1,163

    Default

    Quote Originally Posted by russofris View Post
    I guess that I'm OK with this. The "why are we doing this" is fairly important to me. I just want to be certain that this will be helping us in the case of wanting to load two FOSS drivers. I want to be certain that we're doing this to prevent blobs from interfering with mesa, and not solely to benefit vendors who choose not to take part in the FOSS ecosystem.

    F
    is about to be able to use mesa / nvidia / fglrx / another vendor blob at the same time without script to death your way into it[among many other possible things], about the FOSS im pretty darn sure that nvidia dont wanna take part of the FOSS ecosystem but should make users/distros life lots easier tho

  5. #15
    Join Date
    Sep 2012
    Posts
    4

    Default Will this a affect

    will this affect how older games run such as neverwinter nights, quake 4 and what about older versions of wine that are needed for games that don't run in the current version?
    Last edited by hosh-blot; 09-13-2012 at 03:46 PM.

  6. #16
    Join Date
    Sep 2007
    Posts
    158

    Default

    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.

  7. #17
    Join Date
    Jun 2009
    Posts
    1,163

    Default

    Quote 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

  8. #18
    Join Date
    Aug 2012
    Posts
    8

    Default

    Quote 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?

  9. #19
    Join Date
    Jun 2009
    Posts
    1,163

    Default

    Quote 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

  10. #20
    Join Date
    Jul 2008
    Posts
    1,727

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •