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).
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?
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:
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.
There is a need to deal with general Linux API ABI's in general. The old system can't do this good enough.Quote:
Linux OpenGL ABI
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.