I've just integrated into 4.3.0-17 Jakub Jelinek's optimization patch for Mesa libGL, and would like as many people as possible to test out the new packages. There are several optimizations present, and I'll try to briefly discuss them. Mesa libGL is linked without -fPIC (position independant code), because OpenGL applications are generally considered performance critical, and PIC code has some performance costs which non-PIC code does not. As such, non-PIC is faster and libGL is linked that way by default. One implication of this, is that OpenGL applications linking to Mesa libGL can not be prelinked, because prelinking requires position independant code in order to work. Since libGL isn't PIC, any application or library linking to libGL can not be prelinked. An example of this is the KDE desktop and KDE/Qt applications. KDE/Qt links to libGL, and thus all KDE applications link to libGL even if they don't use it. The major consequence of this, is that if you use prelinking to speed up application startup times in Red Hat Linux (or any distro for that matter), and use KDE, or run any KDE or Qt applications, they wont be prelinked and thus will have slow application startup times, while the rest of your system will not have this limitation. Jakub's patch, moves things around in libGL so that performance critical paths are separate from non-performance critical paths, and the result is that the non-performance critical paths are cleanly prelinkable. This allows applications and libs linking to libGL to be prelinked, and it should be possible to prelink your entire system now presumeably, and enjoy faster startup times all around. In addition, Jakub optimized libGL further to reduce the number of runtime dynamic relocations that need processing at application load time, which further decreases app startup time significantly, even on non-prelinked systems. The patch also causes libGL to be built both without TLS (thread local storage) and with TLS. The TLS enabled libraries require an i686 compatible processor in order to benefit from TLS, however this is all handled automatically and doesn't require the user to know about it. The DRI 3D drivers are also now built 2 ways - the regular way, as well as i686 optimized with TLS, also detected at runtime. The resulting libGL should increase the performance of OpenGL applications to a certain extent, as well as decrease application startup times as described above. No benchmarking has been done on this yet by anyone however so we definitely welcome any kind of real or adhoc benchmark feedback users can provide, both with the hardware DRI drivers (radeon, r128, mga, i810, etc) and also while running software OpenGL (ie: with DRI disabled), both with threaded and non-threaded applications. The more people test this and provide data back the better. Note that these changes do NOT benefit or affect users whom are using 3rd party drivers such as the proprietary binary only Nvidia, ATI, Kyro, 3Dlabs drivers or any other drivers. These changes affect _only_ the open source libGL and the DRI 3D drivers that are included in the XFree86-4.3.0-17 packages. If any bugs are encountered while using these new libGL experimental optimizations, please report them in Red Hat bugzilla against XFree86, and include full details of the problem, steps to reproduce, any word for word error messages displayed on screen. Also attach to your bug report as bugzilla file attachments, your X server log and config file from after encountering an error condition, and your /var/log/messages. Also indicate the exact XFree86 version-release you're testing, and most important - indicate which version of Red Hat Linux you are using, and how you installed the new X packages on it. An important note, is that some of these optimizations are reliant on extremely new gcc and glibc features, and as such require Red hat Linux 9 at a minimum. You may also need to upgrade some packages from rawhide in order to get it to work. As of this writing, this particular build is completely untested, so caveat emptor. If it does fail, be sure to drop a note here as well as to what went wrong. If anyone is interested in trying to get this to work in RHL 8.0 also, feel free to provide feedback as to what changes you had to make to get it going and I'll make a mini-HOWTO. Most importantly, do not install this on mission critical production systems. It is believed to be ok, but is experimental only and not widely tested. Again, caveat emptor. To download this test release of XFree86: http://people.redhat.com/mharris/testing/unstable/XFree86 If you have problems or require help, do not email me privately directly - send email to _this_ mailing list. Myself or someone else may be able to help. Enjoy. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat _______________________________________________ xfree86-list mailing list xfree86-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/xfree86-list IRC: #xfree86 on irc.redhat.com
