On Mon, 2004-02-16 at 16:18, Oliver Baum wrote:
Matthias Guede wrote:
Versuch mal libglut vor der libGL einzubinden.
Vielen Dank! Damit bekomme ich schon mal die undefined references weg. Und das Programm läuft -- allerdings nur mit MESA... :-(
-lGLU -lGL statt -lMesaGLU -lMesaGL
Des weiteren habe ich folgendes die 3D-Hardwarebeschleunigung betreffend herausgefunden: In dem ATI-Treiber von SuSE (erhältlich unter ftp://ftp.suse.com/pub/suse/i386/supplementary/X/XFree86/ATI/suse90/fglrx/3.2.8) ist im Gegensatz zu denen von ATI (von http://www2.ati.com/drivers/linux/fglrx-glc22-4.3.0-3.7.0.i386.rpm) die libGL.so _nicht_ enthalten.
libGL.so ist normalerweise ein Symlink auf die eigentliche libGL.so.X.Y.Z. Da SuSE aber mit libGL.* und den diversen Vendor-Versionen der libGL (NVidia/ATI/Mesa) einige Tricksereien veranstaltet, kann ich Dir mangels SuSE nicht sagen, was SuSE im Detail genau anstellt.
Warum dann aber glxgears bei mir 2200fps erreichte (und tuxracer mit
80fps flüssig lief), bleibt mir weiterhin ein Rätsel... ldd glxgears sollte Dir verraten, welche libGL tatsächlich verwendet wird.
Davon abgesehen, bestehen GLX-Apps wie alle X11-Apps grundsätzlich aus zwei Teilen: Einem auf dem X11-Server laufenden und dem auf dem X11-Client laufenden Teil. Dabei hat der auf dem Server laufenden Teil normalerweise den weitaus überwiegenden Einfluss auf die Performance, egal welche libGL auf Client-Seite verwendet wird. Theoretisch kannst Du dadurch, dass auf Client und auf Server-Seite Vendor-spezifische GL-libs verwendet werden, noch eine weitere Performancesteigerung herausholen, praktisch ist dieser Anteil oft aber kaum messbar. Auch ist es möglich, gegen die Libs eines Vendors zu linken, zur Laufzeit aber die Libs eines anderen Vendors zu verwenden. Gut möglich, dass SuSE diesen Trick verwendet (Linken gegen Mesa, zur Laufzeit Vendor-Libs). Ralf