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 03:49 PM.
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
Originally Posted by mdias
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.
Originally Posted by elanthis
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
Originally Posted by russofris
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 04:46 PM.
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.
too early to say for sure
Originally Posted by hosh-blot
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:
Originally Posted by remm
-----libGL_mesa_2.so[all opengl up to 2.X maybe using an IR like TGSI/LLVM so is GPU indpendant]
-----libGLSL_mesa.so[maybe this can be nice to isolate shader processing]
-----Gallium[convert IR to gpu specific]
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
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.
Originally Posted by RealNC
Gentoo already offers exactly that.