[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LibGL

Użytkownik Lennart Sorensen <lsorense@csclub.uwaterloo.ca> napisał:
>On Wed, Feb 28, 2007 at 09:55:57PM +0100, Leopold Palomo Avellaneda wrote:
>> ummm, for example, without the nvidia-glx, I have:
>>
>> leo@indiana:~$ ls -la /usr/lib64/libGL*
>> lrwxrwxrwx 1 root root     10 2007-02-28 12:42 /usr/lib64/libGL.so -> 
>> libGL.so.1
>> lrwxrwxrwx 1 root root     12 2007-02-28 12:42 /usr/lib64/libGL.so.1 -> 
>> libGL.so.1.2
>> -rw-r--r-- 1 root root 584296 2007-02-23 03:21 /usr/lib64/libGL.so.1.2
>> 
>> ok, is what you are saying. Any program that use the libGL is redirected to 
>> the libGL.so.1, etc. The  glxinfo | grep OpenGL && glxinfo | grep direct 
>> command:
>
>No any program compiled for libGL is compiled for libGL.so.1 which in
>that case there appears to be the mesagl version.
>
>> OpenGL vendor string: NVIDIA Corporation
>> OpenGL renderer string: GeForce FX 5600/AGP/SSE2
>> OpenGL version string: 1.4 (2.0.2 NVIDIA 87.76)
>> OpenGL extensions:
>> direct rendering: No
>
>Yeah that looks like the mesa version.
>
>> ok.
>> 
>> if I install the nvidia-glx package I obtain:
>> 
>> rwxrwxrwx 1 root root     37 2007-02-28 
>> 21:34 /usr/lib64/libGL.so -> /usr/lib/nvidia/libGL.so.1.2.xlibmesa
>> lrwxrwxrwx 1 root root     17 2007-02-28 21:34 /usr/lib64/libGL.so.1 -> 
>> libGL.so.1.0.8776
>> -rw-r--r-- 1 root root 735592 2007-01-05 05:37 /usr/lib64/libGL.so.1.0.8776
>> 
>> and the libGL.so is pointng to /usr/lib/nvidia/libGL.so.1.2.xlibmesa. and this 
>> file is the same as the mesa provides. So, in this case the link is not to 
>> libGL.so.1 . libGL.so.1 is pointing correctly to the nvidia lib. But I have:
>
>libGL.so is for compiling, and since you apparently have the
>libgl1-mesa-dev package installed, then any compiling is done using the
>mesa version of the headers, so libGL.so (used exclusively for
>compiling) links to the mesa version of the library.  If you instead
>installed nvidia-glx-dev, then it would link to the nvidia version,
>since you would be using nvidia's version of those header files.
>
>> leo@indiana:~$ glxinfo | grep OpenGL && glxinfo | grep direct
>> OpenGL vendor string: NVIDIA Corporation
>> OpenGL renderer string: GeForce FX 5600/AGP/SSE2
>> OpenGL version string: 2.0.2 NVIDIA 87.76
>> OpenGL extensions:
>> direct rendering: Yes
>
>Since you have the nvidia version of libGL.so.1 you get DRI.  Without it
>you don't.
>
>> so, if I understand you, if I want to make a program that use libGL 
>> accelerated I have to compile it normally, with the libgl1-mesa-dev
>> - then deinstall the libgl1-mesa-dev library
>> - restart the nvidia-glx
>
>Why would you deinstall the development package?  It has _nothing_ to do
>with running the program.  Any program you compiled will use libGL.so.1
>at runtime, which you showed is a link to the nvidia version of libGL.
>
>> and run the program, that will use the libgl of nvidia instead of the 
>> libgl.xmesa, no?
>
>It will do so without those two steps.
>
>It is as simple as:
>compile program
>run program
>
>It will compile using the mesa headers, and run using the nvidia
>library since they both implement the libGL.so version 1 ABI.
>
>When you compile an opengl program, the linker is told to use libGL
>(-lGL) which it goes looking for.  It find /usr/lib/libGL.so which is a
>symlink to libGL.so.1.2.xlibmesa which is an implementation of libGL,
>shared object, major ABI version 1.  So it writes into the binary that
>it wants libGL.so.1 library loaded dynamically when the program is run.
>It doesn't care who wrote libGL.so.1 as long as it works as the standard
>says it should.  Since both mesa and nvidia implemented the libGL.so
>with the correct ABI, either will work with the resulting program.  When
>you run your program, the loader looks for /usr/lib/libGL.so.1 and finds
>it is a link to libGL.so.1.0.8776 provided by nvidia, and uses that.
>That particular implementation knows how to use an nvidia X server for
>DRI and GLX and hence runs accelerated.  If instead you had a link to
>the mesa version of libGL.so.1 then it would have used that and rendered
>by software (or whatever mesa happens to support on your system).
>
>So the .so is used by linker to find library (name and ABI version) to
>compile for, while at runtime it uses that library name and ABI version
>directly (so in this case libGL.so.1) to load the right library.
>
>--
>Len Sorensen

Let me put a little comment here:P

nvidia drivers do not use DRI, they do direct rendering without it.

Leo - if you are just compiling some OpenGL programs then the mesa
devel (the one you have currently installed) should be just fine.
But if you are willing to develop some OpenGL program then you should
install the nvidia-glx-dev package, just because it gives you the possibility
of writing apps that use everything that your gfx driver supports.

And the extensions.
When something new is introduced to the OpenGL firstly it is an extension.
When the new thing is approved by OpenGL Architecture Review Board
(ARB), then it is implemented in the next version of OpenGL, and in this
next version it is no longer an extension.
When you write an OpenGL program then you can use for example
multitexturing. Multitexturing became a part of OGL in version 1.3. Before
the 1.3 it was only an extension.
Let's say that we live in times of 1.2 version. If you want your program to
use multitexturing, you have to write it in the way that it checks if the
OpenGL driver (on the end-user's system) has the GL_ARB_multitexture
(or sth. like that) extension. If it does't then your program will have to
tell the user something like "sorry, but your OGL driver doesn't support
multitexturing". If it does then your program runs and the user is happy;)
Let's say that some time passes.
The OpenGL 1.3 specification is beeing released and the multitexturing
becomes a standard. What happens then?
Your program checks if there is the GL_ARB_multitexture extension, but
what happens if it is beeing run on some system with OGL v1.3?
It's simple - the driver will tell your app that it has the extension, although
it is not an extension any more. Thanks to that you don't have to rewrite
your code.
But if you wrote your program after the 1.3 was released, then you don't
have to check for the extension - you can check the driver version and
if it is 1.3 or above then you are sure that it supports the multitexturing.
Of course if your program does not use any feature of 1.3 other than
multitexturing, and every other thing is available in version, eg. 1.2, then
you can make your program to check if the driver is in version >=1.2 and
then check for the multitexturing extension. This way users who have some
old gfx card that supports only OGL 1.2, but also multitexturing, will
be able to use your program.

I hope I made it quite clear;)

Tomek
Reply to: