On Thursday 29 September 2005 18:30, Alan Cox wrote: > On Iau, 2005-09-29 at 09:49 +0200, Christoph Hellwig wrote: > > On Wed, Sep 28, 2005 at 04:07:56PM -0700, Andy Ritger wrote: > > > Some of the topics raised include: > > > > > > - minimum OpenGL version required by libGL > > > - SONAME change to libGL > > > - libGL installation path > > > > I think the single most important point is to explicitly disallow > > vendor-supplied libGL binaries in the LSB. Every other LSB componenet > > relies on a single backing implementation for a reason, and in practic > > That is not actually true. It defines a set of API and ABI behaviours > which are generally based on a single existing common implementation. > > > the Nvidia libGL just causes endless pain where people acceidentally > > link against it. The DRI libGL should be declare the one and official > > one, and people who need extended features over it that aren't in the > > driver-specific backend will need to contribute them back. > > If the LSB standard deals with libGL API/ABI interfaces then any > application using other interfaces/feature set items would not be LSB > compliant. Educating users to link with the base libGL is an education > problem not directly inside the LSB remit beyond the LSB test tools. > > In addition the way GL extensions work mean its fairly sane for an > application to ask for extensions and continue using different > approaches if they are not available. In fact this is done anyway for > hardware reasons. There is a lack of "is XYZ accelerated" as an API but > that is an upstream flaw.
The real issue with an IHV-supplied libGL.so is mixing vendors' graphics cards. As an OpenGL user (i.e. a developer of applications that link against libGL), I regularly switch graphics cards around to make sure things work with all the relevant major vendors. Having a vendor-supplied libGL.so makes this unnecessarily difficult on the software side (add to that the custom-installed header files that have ever so slightly different semantics, and there is a whole lot of fun to be had). Not to mention the use case with two graphics cards installed at the same time, from different vendors. While the above problem is annoying but acceptable, there's simply no reasonable way to use two graphics cards from vendors that insist on their custom libGL.so. Having to hack around with LD_LIBRARY_PATH and the likes is ridiculous. I'm not too familiar with the exact details of the DRI client-server protocol, so maybe it may be necessary to turn the libGL.so into even more of a skeleton, and reduce the basic DRI protocol to a simple "tell me the client side driver name", so that IHVs can combine (for example) custom GLX extensions with direct rendering. cu, Nicolai
pgpeJXl3bNGf2.pgp
Description: PGP signature
