| Summary: | Still required to compile libGL without PIC on i386? | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Stefan Dirsch <sndirsch> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | high | CC: | ajax, eich, erik.andren, mat, roland.mainz |
| Version: | git | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
thank you for testing this. i've been wanting real numbers comparing PIC and non-PIC libGL for a while now. i'm all for turning -fPIC back on. (In reply to comment #0) > non-PIC PIC > drv-09 3.928 3.282 the others show insiginificant differences, but I would say the 20% here is quite a large difference. We did see significant differences with glxgears. Though I must agree that viewperf is a more reasonable benchmark. This was when we wondered about the performance difference between drivers built from the Xorg/DRI trees and the Mesa tree. It turned out it was due to the use -fPIC in Mesa. By now -fPIC is not used in Mesa any more (on i386) for exactly that reason. I'm not perfectly happy with ViewPerf, there's too much stuff going on behind the scenes (and AFAIR it is quite CPU intesive as well). I'll try do some performance tests with machtest (my own benchmark) for obtaining some plain geometry transformation rates. Couldn't do that until now because I didn't have a working GL driver until yesterday... :P There's a pretty neat newish benchmarker called FrameGetter. You can read some more about it at http://www.anandtech.com/linux/showdoc.aspx?i=2218 and download it from http://www.anandtech.com/linux/showdoc.aspx?i=2229&p=2. Ok, some numbers from my side: 4x4 size triangles, color per vertex. i915 with i810 driver, R200 with radeon driver. Tested with machtest (http://www.vis.uni-stuttgart.de/machtest/ - don't tell me that it's old, I know that myself =P ). i915 nopic i915 pic R200 nopic R200 pic glVertex3f() w/o lighting: 2.43 M/s 2.44 M/s 5.46 M/s 5.46 M/s glVertex3f() w/ 7 lights: 645 k/s 643 k/s 1.89 M/s 1.88 M/s glVertexArray() size 900 w/o l: 3.82 M/s 3.82 M/s 4.72 M/s 4.72 M/s So the difference is much smaller than the typical jitter between different calls. The more vertices are sent down the framebuffer, the higher is the relative overhead of pic vs. nopic. So I'm especially happy to see the R200 w/ glVertex3f() equally fast. Unfortunately, I cannot present results from modern cards, as a) the nvidia driver only works with its own libGL b) the beta fglrx driver for Xorg only works with its own libGL (former versions did work with mesa libGL) - mesa's libGL just says 'direct rendering: no' - and vice versa! That is the radeon driver does not work with the fglrx libGL! Besides, the beta fglrx driver is broken WRT other aspects as well (e.g. array rendering of arrays >900 vertices does not work as anticipated). Facit: there is *no* meassurable performance difference between pic and nopic. Nuke the nopic config. (In reply to comment #2) > (In reply to comment #0) > > non-PIC PIC > > drv-09 3.928 3.282 > the others show insiginificant differences, but I would say the 20% here is > quite a large difference. I guess this was typical jitter. Stefan told me that this was a quick test. There is nothing in libGL that requires more function calls than rendering triangles with one call per vertex (glVertex3f()). Anyone, who is brave enough to commit the change to use "-fPIC" on i386 again? Is -fPIC turned on by now? Ping! "-fPIC" is still not set on i386. Since Mesa is no longer in the current X.Org tree I'm changing product to Mesa. Looks like "-fPIC" is now set also for i386. Checked with Mesa-7.0.2-rc1. But I still get this error # sudo /usr/sbin/prelink /usr/lib/xscreensaver/spheremonics /usr/sbin/prelink: /usr/lib/xscreensaver/spheremonics: shared library /usr/lib/libGL.so.1.2 appears possibly non-PIC and contains conflicts. Symbol offset: 414048b7 Strange ... One thing Mesa doesn't do, but libtool does, is pass -DPIC to the compiler. You could try setting that in the DEFINES for the config you're using and see if that helps. I don't have prelink here to play with, but I'll try to get it. I don't think "-DPIC" does change anything. But removing "PIC_FLAGS =" in configs/linux-dri-x86 fixes the prelink issue. (In reply to comment #12) > Looks like "-fPIC" is now set also for i386. Checked with Mesa-7.0.2-rc1. I was wrong. Date: Tue, 06 Nov 2007 18:00:53 -0700 To: MESA-Devel <Mesa3d-dev@lists.sourceforge.net>, mesa3d-users <mesa3d-users@lists.sourceforge.net>, mesa3d-announce@lists.sourceforge.net From: Brian Paul <brian.paul@tungstengraphics.com> Subject: [Mesa3d-announce] Mesa 7.0.2 release candidate 2 Second release candidate at http://www.mesa3d.org/beta/ Since rc1: added -fPIC and -fno-strict-aliasing flags for gcc [...] -Brian Mass version move, cvs -> git |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
% prelink /usr/lib/xscreensaver/spheremonics prelink: /usr/lib/xscreensaver/spheremonics: shared library /usr/lib/libGL.so.1.2 appears possibly non-PIC and contains conflicts. Symbol offset: 413205fc It turns out that shared libGL is still built without PIC on i386. linux.cf: [...] /* * Build shared libGL and the DRI modules without -fPIC on some architectures. * This improves performance. */ #if BuildXF86DRI # if defined(i386Architecture) # define BuildLibGlxWithoutPIC YES # endif #endif [...] revision 3.162 date: 2001/04/03 02:29:30; author: dawes; state: Exp; lines: +9 -1 320. Build shared libGL and DRI client modules on Linux without PIC for performance reasons. I finally did some testing with PIC/non-PIC with viewperf 7.1.1: (Radeon 7500, AMD64 1.6 GHz, 1 GB Memory, 32bit) non-PIC PIC 3dsmax-02 3.047 3.049 drv-09 3.928 3.282 dx-08 19.06 19.00 light-06 3.433 3.373 proe-02 2.328 2.319 ugs-03 1.492 1.434 I can't see any significant differences. Therefore I propose to enable PIC for libGL again. What do you think? Maybe gcc has improved a *lot* in the last 3 years, so this is no longer required?