Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 11-07-03, 03:38 PM   #1
hmh
Registered User
 
Join Date: Nov 2003
Posts: 3
Lightbulb Please provide prelink-able (i.e. PIC mode) libGL.so.1

As you may or may not know, most platforms (including all that nVidia supports AFAIK) are able to use prelinked binaries with new glibc, such as what is going to ship in new releases from Debian and RedHat.

Some distributions, such as Debian, are moving so that just about everything can be prelinked if the user so wishes. A prelinked binary loads MUCH faster (as in up to 60 times faster). However, all libraries must be prelinked to all their dependencies for a binary to be prelinked.

For prelinking to work on IA32, the libraries all need to be linked in position-independent-code mode (PIC). This is actually a requirement for a library be dynamic at all in many platforms, but IA32 can work with non-PIC dynamic libraries.

The current libGL.so.1 from nVidia is such a beast. It is a dynamic library, compiled in non-PIC mode (for IA32 anyway).

This means that *ALL* X11 programs that use openGL in the entire computer cannot be prelinked properly. Ugh.

Could nVidia provide an alternative PIC mode library for us who want it? The only difference is that all source of the libGL.so.1 file must be compiled with the -fPIC flag of gcc, nVidia already does the rest of the stuff needed for prelinking.

-fPIC won't change much of anything for anyone else, although there IS a small chance it might make some operations slower (PIC code is a few microseconds slower in some CPUs, but not in the P4s and A7s of today's age AFAIK), so I am asking for it to be an option, not the default.

More data on prelinking can be found at:
http://sources.redhat.com/ml/libc-al.../msg00113.html
http://gcc.gnu.org/ml/gcc/2001-05/msg01670.html

(do note that prelink has come a LONG way since 2001 )
hmh is offline   Reply With Quote
Old 02-21-04, 03:37 AM   #2
Ronald
Registered User
 
Join Date: Apr 2003
Posts: 7
Send a message via ICQ to Ronald
Default

It is really too bad nobody replies to this thread, I was about to send a request about this to nvidia as well, but first, lets try to show my support for this idea trough this.

Nvidia, please provide a -fPIC compiled libGL.so

It is as easy as rebuild all object files with -fPIC as gcc option. You won't be putting any trade secrets on the line with this (well not more then the non PIC library at least ;-) )

Note: static libraries should not be build with -fPIC!
Ronald is offline   Reply With Quote
Old 02-21-04, 05:03 AM   #3
zander
NVIDIA Corporation
 
zander's Avatar
 
Join Date: Aug 2002
Posts: 3,740
Default

Building libGL.so with -fPIC on i386, you would be trading in quite a bit of runtime performance for startup time; is that really what you want?
zander is offline   Reply With Quote
Old 02-21-04, 05:48 AM   #4
Ronald
Registered User
 
Join Date: Apr 2003
Posts: 7
Send a message via ICQ to Ronald
Default

Quote:
-fPIC won't change much of anything for anyone else, although there IS a small chance it might make some operations slower (PIC code is a few microseconds slower in some CPUs, but not in the P4s and A7s of today's age AFAIK), so I am asking for it to be an option, not the default.
If -fPIC were indeed a lot slower runtime, why does EVERY single distro out there build shared libs -fPIC ?

Furthermore: the request is for an optional -fPIC build binary, not the default so in any case you have the choice.
Ronald is offline   Reply With Quote
Old 02-21-04, 07:17 AM   #5
zander
NVIDIA Corporation
 
zander's Avatar
 
Join Date: Aug 2002
Posts: 3,740
Default

Most shared libraries aren't in performance critical paths, libGL.so is; -fPIC is expensive on i386 (it eats a register, introduces undesired indirection). I expect NVIDIA wouldn't agree that providing an optional -fPIC build is simple, the NPTL/TLS situation serves as a good example for the maintenance overhead and the numerous problems that shipping multiple copies of libGL.so can introduce. Even if building/shipping an -fPIC libGL.so didn't introduce technical problems, it would certainly lead to confusion and quite likely produce reports of mysterious performance degredations.

It is my understanding that (for many/most users, at least) the lack of a -fPIC libGL.so is a problem only because libqt is linked against libGL.so unconditionally, even though hardly any Qt application interacts with or has dependencies on OpenGL. I believe some work has been done to change this behavior.
zander is offline   Reply With Quote
Old 02-21-04, 08:30 AM   #6
hmh
Registered User
 
Join Date: Nov 2003
Posts: 3
Default

Quote:
-fPIC is expensive on i386 (it eats a register, introduces undesired indirection).
and
Quote:
Most shared libraries aren't in performance critical paths, libGL.so is
This is only true if your system is purely a gaming platform (which is unlikely if you are using Linux, since it is NOT the best gaming platform to begin with -- you cannot get most of the games). For an user which uses OpenGL for day-to-day activities (such as real 3D/transparency on the window manager), startup times are often much more important than a very small speed penalty on the GL code (if there is any noticeable one for nVidia libGL1 in recent ia32 platforms, I don't have a way to benchmark this here).

I guess I could have phrased the request "please provide a day-to-day optimized version of libGL1.so" (i.e. a -fPIC compiled one). Anyway, getting Qt to stop linking to libGL needlessly certainly will improve things a bit... until we start using OpenGL everywhere for real (which is NOT that far in the future), that is.

In that case, non-PIC code not only has extreme startup penalties, it also wastes memory, AFAIK: non-PIC code can't really be shared across processes due to the memory maps, no? It is dynamic loadable, but NOT shared. This is not a problem if only one or two apps are using OpenGL, but it does not scale at all...
hmh is offline   Reply With Quote
Old 02-21-04, 09:46 AM   #7
zander
NVIDIA Corporation
 
zander's Avatar
 
Join Date: Aug 2002
Posts: 3,740
Default

Depending on the nature and complexity of the given OpenGL applications, the -fPIC performance hit would be more than merely noticeable; your arguments that performance is bought with higher overall memory usage and startup relocation complexity are certainly valid, but runtime performance requirements are anything but specific to games (consider professional workstations). If OpenGL was indeed used for everything in the near future (something I'm not convinced will happen on Linux anytime soon, if at all) I would want it to be fast more than ever before. In any case, the typical GNU/Linux workstation today makes use of OpenGL for specific applications only, and prelink isn't widely used. The Qt/OpenGL/prelink difficulties are unfortunate, but I don't think the NVIDIA driver represents an unsurmountable, technical obstacle.
zander is offline   Reply With Quote
Old 02-21-04, 10:19 AM   #8
hmh
Registered User
 
Join Date: Nov 2003
Posts: 3
Default

Quote:
Depending on the nature and complexity of the given OpenGL applications, the -fPIC performance hit would be more than merely noticeable;
Would it? How much penalty are we talking here for PIC code in the critical path?

PIC code will only make a noticeable difference in speed if it is in the critical path, AND even then, it may not be noticeable if the penalty is small enough. If I find the time, I will kill the nVidia GLX install, and try to benchmark MESA with and without PIC code. But that could take a major while. If someone else has a bit more spare time, please do so. Even glxgears will provide a good enough benchmark if the PIC penalty is indeed that big.

Obviously, this is all moot if we are given the option of using a PIC or a non-PIC library, which is what I asked for in the first place...
hmh is offline   Reply With Quote

Old 02-21-04, 10:25 AM   #9
Ronald
Registered User
 
Join Date: Apr 2003
Posts: 7
Send a message via ICQ to Ronald
Default

If the extra register use is THAT critical on x86, then why is the penalty of NOT compiling with -fomit-frame-pointer not very significant.

I have no idea about wether nvidia's libGL.so is compiled with or without frame pointers, but i'm guessing somebody with experience with the debugger should be able to figure out. If the register is critical i hope its build with the flag

Any case, an nvidia developer could benchmark around and tell us what the penalty is. Until then... we are in the dark.
Ronald is offline   Reply With Quote
Old 07-27-04, 02:27 AM   #10
sindre1
Registered User
 
Join Date: Jul 2004
Posts: 3
Default Re: Please provide prelink-able (i.e. PIC mode) libGL.so.1

Are you working on this issue yet? You should at least warn users that kde and any qt-app will be noticably slower with your driver than with any other.

Please do something about this, or at least explain why it's not possible. It's not nice to pretend it doesn't exist, just because most users don't know about technicalities.

Last edited by sindre1; 07-27-04 at 08:32 AM.
sindre1 is offline   Reply With Quote
Old 07-27-04, 03:18 AM   #11
zander
NVIDIA Corporation
 
zander's Avatar
 
Join Date: Aug 2002
Posts: 3,740
Default Re: Please provide prelink-able (i.e. PIC mode) libGL.so.1

To the best of my knowledge, Qt >= 3.3.0 offers a configure option (--dlopen-opengl) that removes its hard-wired dependency on libGL (which is then loaded on demand); this allows you to prelink Qt/KDE applications even with the NVIDIA driver present on your system.
zander is offline   Reply With Quote
Old 07-27-04, 04:16 AM   #12
sindre1
Registered User
 
Join Date: Jul 2004
Posts: 3
Default Re: Please provide prelink-able (i.e. PIC mode) libGL.so.1

Semms you're right
I'll try recompiling qt with opengl-support and see if it works.
sindre1 is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


Similar Threads
Thread Thread Starter Forum Replies Last Post
320.17 can't detect video modes on Lenovo laptop tadawson NVIDIA Linux 13 07-14-12 02:40 AM
Very slow X startup Jeremy NVIDIA Linux 96 05-23-03 11:11 AM
Error messages... HELP!!!! Imperito NVIDIA Linux 3 09-24-02 11:46 PM
Nvidia GF4 MX 440 + Mandrake tomchristopher NVIDIA Linux 3 08-18-02 10:42 AM
nVidia drivers + Red Hat Linux 7.3 Error404 NVIDIA Linux 17 08-16-02 12:34 PM

All times are GMT -5. The time now is 12:52 PM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.