A New Linux OpenGL ABI Is Being Proposed

[elanthis]

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.

[DeepDayze]

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

[russofris]

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

[jrch2k8]

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

[hosh-blot]

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?

[remm]

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.

[jrch2k8]

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

[calubi]

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?

[jrch2k8]

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

[energyman]

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.