Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...

2013-09-12 Thread Christian König 

I completely agree.

Building everything shared might speed up the build process a little bit 
and save some space, but for the cost of having to handle allot of 
rather small shared libraries where which each clashing the symbol space 
of any application using these drivers with a bunch of unnecessary symbols.


Building everything as one big blob sounds like the better idea.

Christian.

Am 12.09.2013 02:03, schrieb Marek Olšák:

BTW, the build system fixes would be good to have anyway, but I'm not
an expert on the Mesa build system.

Marek

On Thu, Sep 12, 2013 at 1:51 AM, Marek Olšák mar...@gmail.com wrote:

I don't like this. I prefer to have one big blob for whole Mesa as
discussed on Eric's blog:

http://anholt.livejournal.com/43652.html

I have no problem with longer compile times for release builds if I
get a little bit higher CPU performance with link-time optimizations.
And for debug builds, we can stick to standard -O2 -g or -O0 -g.

Marek

On Thu, Sep 12, 2013 at 12:32 AM, Johannes Obermayr
johannesoberm...@gmx.de wrote:

[PATCH 01/21] ilo: Fix out-of-tree build.

[PATCH 02/21] Suppress clang's warnings about unused CFLAGS and CXXFLAGS.

[PATCH 03/21] configure.ac: Save user {C,CXX}FLAGS and append them at end.

[PATCH 04/21] radeon: Build and use libradeon the right way.
   Link libradeon only once in egl-static

[PATCH 05/21] gallium/targets: Make use of prebuilt libdricommon.la.
   Avoid duplicate build.

[PATCH 06/21] Drop support for --enable-static / --disable-shared.

[PATCH 07/21] gallium/auxiliary: Build libgallium shared.
   Hundreds of symbols to be PUBLIC. But saves on a full build
   19 x ~ 1.8 MB.

[PATCH 08/21] Drop last parts of compatibility for the old Mesa build
   I want it to avoid these stupid symlinks while distro build but
   with more work on follow-up patches it should be possible to keep

[PATCH 09/21] mapi: Build libglapi always shared.
   I assume it could be improved later

[PATCH 10/21] mesa: Build libmesa shared.
   Hundreds of PUBLICs but we can get rid of libdricore and get an
   libmesadri which depends as well as libmesagallium on a 
libmesacore.
   This really speeds up build since duplicate build in libdricore
   with all PUBLIC can be avoided.
   Also dlopen classic drivers should be faster.

[PATCH 11/21] Install all internal shared libs to $(libdir)/mesa-$VERSION.

[PATCH 12/21] Also do it for egl_gallium.so, pipe_*.so and gbm_gallium_drm.

[PATCH 13/21] Makefile.am: s:-no-undefined:-Wl,--no-undefined to make it work.
   libtool will set it back to allow_undefined=yes in 
func_mode_link ()
   otherwise.

[PATCH 14/21] gallium/drivers: Build libs -shared.

[PATCH 15/21] vdpau,xvmc: Add install-data-hooks to remove unneccessary 
symlinks.
   libvdpau_*.so.1 and libXvMC*.so libs are dlopened by wrappers.
   Nothing should link them directly.

[PATCH 16/21] glx: Get rid of libglx.la.

[PATCH 17/21] gbm: Get rid of libgbm_dri.la.

[PATCH 18/21] i915: Conditionally build an i915g driver instead of

[PATCH 19/21] freedreno: Make print_sequence a macro to fix clang.

[PATCH 20/21] freedreno: One Makefile.am with a Makefile.sources is

[PATCH 21/21] clover: Force gcc and g++ to fix clang builds.


openSUSE x86_64 binary RPMs will look like this:
$ du -a etc/ usr/
4   etc/drirc
8   etc/
88  usr/lib64/libXvMCr600.so
140 usr/lib64/libEGL.so.1.0.0
0   usr/lib64/libGL.so.1.2
380 usr/lib64/libGL.so.1.2.0
0   usr/lib64/libGLESv1_CM.so.1
88  usr/lib64/libXvMCr300.so
36  usr/lib64/libXvMCsoftpipe.so
212 usr/lib64/mesa-9.2.0/libllvmpipe.so
608 usr/lib64/mesa-9.2.0/libmesadri.so
324 usr/lib64/mesa-9.2.0/libmesagallium.so
1140usr/lib64/mesa-9.2.0/libnouveau.so
60  usr/lib64/mesa-9.2.0/libtrace.so
60  usr/lib64/mesa-9.2.0/pipe_r600.so
308 usr/lib64/mesa-9.2.0/libr300.so
20  usr/lib64/mesa-9.2.0/libgalahad.so
16  usr/lib64/mesa-9.2.0/libnoop.so
32  usr/lib64/mesa-9.2.0/librbug.so
60  usr/lib64/mesa-9.2.0/pipe_r300.so
60  usr/lib64/mesa-9.2.0/pipe_radeonsi.so
164 usr/lib64/mesa-9.2.0/egl_gallium.so
152 usr/lib64/mesa-9.2.0/libglapi.so
136 usr/lib64/mesa-9.2.0/libradeonsi.so
16  usr/lib64/mesa-9.2.0/libr300-helper.so
16  usr/lib64/mesa-9.2.0/libidentity.so
8   usr/lib64/mesa-9.2.0/pipe_nouveau.so
184 usr/lib64/mesa-9.2.0/libsvga.so
1888usr/lib64/mesa-9.2.0/libgallium.so
20  usr/lib64/mesa-9.2.0/gbm_gallium_drm.so
1016usr/lib64/mesa-9.2.0/libr600.so
20  usr/lib64/mesa-9.2.0/pipe_vmwgfx.so
3228usr/lib64/mesa-9.2.0/libmesacore.so
152 usr/lib64/mesa-9.2.0/libsoftpipe.so
8   usr/lib64/mesa-9.2.0/pipe_swrast.so
9912usr/lib64/mesa-9.2.0
0   usr/lib64/libOSMesa.so.8
0   usr/lib64/libxatracker.so.1
64  usr/lib64/dri/swrast_dri.so
184

Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...

2013-09-12 Thread Mathias Fröhlich 

Hi,

On Thursday, September 12, 2013 08:41:10 Christian König wrote:
 I completely agree.
 
 Building everything shared might speed up the build process a little bit
 and save some space, but for the cost of having to handle allot of
 rather small shared libraries where which each clashing the symbol space
 of any application using these drivers with a bunch of unnecessary symbols.
 
 Building everything as one big blob sounds like the better idea.
+1.

Symbol clashes with libraries used in drivers are a huge problem for 
applications that either ship with their own version/variant of this kind of 
library and do not expect to have a second one injected by the side effect of a 
user space driver or in case of LLVM just because of this not being reliably 
thread safe. If your driver knows the version and instance of llvm it has 
linked with, because it's its own internal one technically hidden from all 
other potential users we will see less unwanted side effects.

To get this symbol clash problem right, there could be an other solution I 
have been playing with which is loading the drivers with RTLD_DEEPBIND. I am 
running with patches for this already for a long time here but I never found 
the time to test this for side effects on OpenCL use. The problem that still 
needs to be investigated there is that you want to share buffer objects between 
OpenCL and OpenGL and for that you work you might(?) need a single instance of 
libdrm in the application. Also this dlopen flag is not part of the standard 
that covers dlopen and thus not avaiable everywhere.

What problem do you want to solve exactly with this shared library split?

If you care for memory use of the running application, you will need to have 
the driver binary loaded including all its code. Having a big blob without any 
relocs in between increases the probability that you can reuse read only pages 
for the code segments to be shared between applications.
Note that the RTLD_DEEPBIND variant above uses even more memory in the running 
application since each dlopened driver gets it's own private set of mapped 
shared objects.

If you care about on disc use which might be interresting for small embedded 
like machines, is it possible to split the drivers rpm into seperate pieces 
per driver? That way an embedded system integrator could potentially install 
them individually based on the available hardware for such a specific case?

Greetings

Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...

2013-09-12 Thread Kenneth Graunke 
On 09/11/2013 11:41 PM, Christian König wrote:
 I completely agree.
 
 Building everything shared might speed up the build process a little bit
 and save some space, but for the cost of having to handle allot of
 rather small shared libraries where which each clashing the symbol space
 of any application using these drivers with a bunch of unnecessary symbols.
 
 Building everything as one big blob sounds like the better idea.
 
 Christian.

Not to mention...installing a ton of shared libraries is just asking for
version mismatch problems.  I've had a /ton/ of problems due to
mismatching libdricore and i965_dri.so...usually due to rpath shenanigans.

If anything, I'd like to get rid of libdricore and build core Mesa and
the drivers together again.  No more version clashes.  Far fewer symbols
exported.  LTO for extra performance with no extra effort...

Faster build times are nice, but...not if it means shipping a ton of
shared libraries...

--Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...

2013-09-12 Thread Johannes Obermayr 
I see current situation is better:

Symbol table '.dynsym' contains ...

master:

libdricore: 3675
i965_dri:398


after [PATCH 10/21]:

classic drivers:
libmesacore: 839
libmesadri:  348
total:  1187
i965_dri:397

gallium drivers:
libgallium:  833
libmesacore: 839
libmesagallium:  360
total:  2032

Complaining about the weather instead of opening the shutter to see the sun.

Am Donnerstag, 12. September 2013, 00:44:58 schrieb Kenneth Graunke:
 On 09/11/2013 11:41 PM, Christian König wrote:
  I completely agree.
  
  Building everything shared might speed up the build process a little bit
  and save some space, but for the cost of having to handle allot of
  rather small shared libraries where which each clashing the symbol space
  of any application using these drivers with a bunch of unnecessary symbols.
  
  Building everything as one big blob sounds like the better idea.
  
  Christian.
 
 Not to mention...installing a ton of shared libraries is just asking for
 version mismatch problems.  I've had a /ton/ of problems due to
 mismatching libdricore and i965_dri.so...usually due to rpath shenanigans.
 
 If anything, I'd like to get rid of libdricore and build core Mesa and
 the drivers together again.  No more version clashes.  Far fewer symbols
 exported.  LTO for extra performance with no extra effort...
 
 Faster build times are nice, but...not if it means shipping a ton of
 shared libraries...
 
 --Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...

2013-09-12 Thread Marek Olšák 
I think current Gallium drivers only need one exported symbol to work:
__driDriverExtensions. See:
http://lists.freedesktop.org/archives/mesa-dev/2013-August/043038.html

Marek

On Thu, Sep 12, 2013 at 2:41 PM, Johannes Obermayr
johannesoberm...@gmx.de wrote:
 I see current situation is better:

 Symbol table '.dynsym' contains ...

 master:

 libdricore: 3675
 i965_dri:398


 after [PATCH 10/21]:

 classic drivers:
 libmesacore: 839
 libmesadri:  348
 total:  1187
 i965_dri:397

 gallium drivers:
 libgallium:  833
 libmesacore: 839
 libmesagallium:  360
 total:  2032

 Complaining about the weather instead of opening the shutter to see the sun.

 Am Donnerstag, 12. September 2013, 00:44:58 schrieb Kenneth Graunke:
 On 09/11/2013 11:41 PM, Christian König wrote:
  I completely agree.
 
  Building everything shared might speed up the build process a little bit
  and save some space, but for the cost of having to handle allot of
  rather small shared libraries where which each clashing the symbol space
  of any application using these drivers with a bunch of unnecessary symbols.
 
  Building everything as one big blob sounds like the better idea.
 
  Christian.

 Not to mention...installing a ton of shared libraries is just asking for
 version mismatch problems.  I've had a /ton/ of problems due to
 mismatching libdricore and i965_dri.so...usually due to rpath shenanigans.

 If anything, I'd like to get rid of libdricore and build core Mesa and
 the drivers together again.  No more version clashes.  Far fewer symbols
 exported.  LTO for extra performance with no extra effort...

 Faster build times are nice, but...not if it means shipping a ton of
 shared libraries...

 --Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...

2013-09-12 Thread Johannes Obermayr 
Am Donnerstag, 12. September 2013, 14:52:15 schrieb Marek Olšák:
 I think current Gallium drivers only need one exported symbol to work:
 __driDriverExtensions. See:
 http://lists.freedesktop.org/archives/mesa-dev/2013-August/043038.html
 
 Marek

readelf -s usr/lib64/dri/radeonsi_dri.so 

master:
Symbol table '.dynsym' contains 556 entries:

after patch series:
Symbol table '.dynsym' contains 153 entries:

 
 On Thu, Sep 12, 2013 at 2:41 PM, Johannes Obermayr
 johannesoberm...@gmx.de wrote:
  I see current situation is better:
 
  Symbol table '.dynsym' contains ...
 
  master:
 
  libdricore: 3675
  i965_dri:398
 
 
  after [PATCH 10/21]:
 
  classic drivers:
  libmesacore: 839
  libmesadri:  348
  total:  1187
  i965_dri:397
 
  gallium drivers:
  libgallium:  833
  libmesacore: 839
  libmesagallium:  360
  total:  2032
 
  Complaining about the weather instead of opening the shutter to see the sun.
 
  Am Donnerstag, 12. September 2013, 00:44:58 schrieb Kenneth Graunke:
  On 09/11/2013 11:41 PM, Christian König wrote:
   I completely agree.
  
   Building everything shared might speed up the build process a little bit
   and save some space, but for the cost of having to handle allot of
   rather small shared libraries where which each clashing the symbol space
   of any application using these drivers with a bunch of unnecessary 
   symbols.
  
   Building everything as one big blob sounds like the better idea.
  
   Christian.
 
  Not to mention...installing a ton of shared libraries is just asking for
  version mismatch problems.  I've had a /ton/ of problems due to
  mismatching libdricore and i965_dri.so...usually due to rpath shenanigans.
 
  If anything, I'd like to get rid of libdricore and build core Mesa and
  the drivers together again.  No more version clashes.  Far fewer symbols
  exported.  LTO for extra performance with no extra effort...
 
  Faster build times are nice, but...not if it means shipping a ton of
  shared libraries...
 
  --Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...

2013-09-12 Thread Christian König 

Am 12.09.2013 14:52, schrieb Marek Olšák:

I think current Gallium drivers only need one exported symbol to work:
__driDriverExtensions. See:
http://lists.freedesktop.org/archives/mesa-dev/2013-August/043038.html


Yes that's indeed the right way of doing it, feel free to make the 
changes Chia-l Wu suggested to avoid the version file and commit the 
patch with my rb.


Christian.


Marek

On Thu, Sep 12, 2013 at 2:41 PM, Johannes Obermayr
johannesoberm...@gmx.de wrote:

I see current situation is better:

Symbol table '.dynsym' contains ...

master:

libdricore: 3675
i965_dri:398


after [PATCH 10/21]:

classic drivers:
libmesacore: 839
libmesadri:  348
total:  1187
i965_dri:397

gallium drivers:
libgallium:  833
libmesacore: 839
libmesagallium:  360
total:  2032

Complaining about the weather instead of opening the shutter to see the sun.

Am Donnerstag, 12. September 2013, 00:44:58 schrieb Kenneth Graunke:

On 09/11/2013 11:41 PM, Christian König wrote:

I completely agree.

Building everything shared might speed up the build process a little bit
and save some space, but for the cost of having to handle allot of
rather small shared libraries where which each clashing the symbol space
of any application using these drivers with a bunch of unnecessary symbols.

Building everything as one big blob sounds like the better idea.

Christian.

Not to mention...installing a ton of shared libraries is just asking for
version mismatch problems.  I've had a /ton/ of problems due to
mismatching libdricore and i965_dri.so...usually due to rpath shenanigans.

If anything, I'd like to get rid of libdricore and build core Mesa and
the drivers together again.  No more version clashes.  Far fewer symbols
exported.  LTO for extra performance with no extra effort...

Faster build times are nice, but...not if it means shipping a ton of
shared libraries...

--Ken


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...

2013-09-12 Thread Ian Romanick 
On 09/12/2013 02:44 AM, Kenneth Graunke wrote:
 On 09/11/2013 11:41 PM, Christian König wrote:
 I completely agree.

 Building everything shared might speed up the build process a little bit
 and save some space, but for the cost of having to handle allot of
 rather small shared libraries where which each clashing the symbol space
 of any application using these drivers with a bunch of unnecessary symbols.

 Building everything as one big blob sounds like the better idea.

 Christian.
 
 Not to mention...installing a ton of shared libraries is just asking for
 version mismatch problems.  I've had a /ton/ of problems due to
 mismatching libdricore and i965_dri.so...usually due to rpath shenanigans.

The existing number of shared libraries already makes it a giant pain in
the ass to build and test multiple Mesa versions (master, 9.2.x, 9.1.x,
branches, etc.).  I'm not interested in seeing anything land that
exacerbates that problem.

 If anything, I'd like to get rid of libdricore and build core Mesa and
 the drivers together again.  No more version clashes.  Far fewer symbols
 exported.  LTO for extra performance with no extra effort...
 
 Faster build times are nice, but...not if it means shipping a ton of
 shared libraries...
 
 --Ken
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] The long way to a faster build with shared libs and some fixes ...

2013-09-11 Thread Johannes Obermayr 
[PATCH 01/21] ilo: Fix out-of-tree build.

[PATCH 02/21] Suppress clang's warnings about unused CFLAGS and CXXFLAGS.

[PATCH 03/21] configure.ac: Save user {C,CXX}FLAGS and append them at end.

[PATCH 04/21] radeon: Build and use libradeon the right way.
  Link libradeon only once in egl-static

[PATCH 05/21] gallium/targets: Make use of prebuilt libdricommon.la.
  Avoid duplicate build.

[PATCH 06/21] Drop support for --enable-static / --disable-shared.

[PATCH 07/21] gallium/auxiliary: Build libgallium shared.
  Hundreds of symbols to be PUBLIC. But saves on a full build
  19 x ~ 1.8 MB.

[PATCH 08/21] Drop last parts of compatibility for the old Mesa build
  I want it to avoid these stupid symlinks while distro build but
  with more work on follow-up patches it should be possible to keep

[PATCH 09/21] mapi: Build libglapi always shared.
  I assume it could be improved later

[PATCH 10/21] mesa: Build libmesa shared.
  Hundreds of PUBLICs but we can get rid of libdricore and get an
  libmesadri which depends as well as libmesagallium on a 
libmesacore.
  This really speeds up build since duplicate build in libdricore
  with all PUBLIC can be avoided.
  Also dlopen classic drivers should be faster.

[PATCH 11/21] Install all internal shared libs to $(libdir)/mesa-$VERSION.

[PATCH 12/21] Also do it for egl_gallium.so, pipe_*.so and gbm_gallium_drm.

[PATCH 13/21] Makefile.am: s:-no-undefined:-Wl,--no-undefined to make it work.
  libtool will set it back to allow_undefined=yes in func_mode_link 
()
  otherwise.

[PATCH 14/21] gallium/drivers: Build libs -shared.

[PATCH 15/21] vdpau,xvmc: Add install-data-hooks to remove unneccessary 
symlinks.
  libvdpau_*.so.1 and libXvMC*.so libs are dlopened by wrappers.
  Nothing should link them directly.

[PATCH 16/21] glx: Get rid of libglx.la.

[PATCH 17/21] gbm: Get rid of libgbm_dri.la.

[PATCH 18/21] i915: Conditionally build an i915g driver instead of

[PATCH 19/21] freedreno: Make print_sequence a macro to fix clang.

[PATCH 20/21] freedreno: One Makefile.am with a Makefile.sources is

[PATCH 21/21] clover: Force gcc and g++ to fix clang builds.


openSUSE x86_64 binary RPMs will look like this:
$ du -a etc/ usr/
4   etc/drirc
8   etc/
88  usr/lib64/libXvMCr600.so
140 usr/lib64/libEGL.so.1.0.0
0   usr/lib64/libGL.so.1.2
380 usr/lib64/libGL.so.1.2.0
0   usr/lib64/libGLESv1_CM.so.1
88  usr/lib64/libXvMCr300.so
36  usr/lib64/libXvMCsoftpipe.so
212 usr/lib64/mesa-9.2.0/libllvmpipe.so
608 usr/lib64/mesa-9.2.0/libmesadri.so
324 usr/lib64/mesa-9.2.0/libmesagallium.so
1140usr/lib64/mesa-9.2.0/libnouveau.so
60  usr/lib64/mesa-9.2.0/libtrace.so
60  usr/lib64/mesa-9.2.0/pipe_r600.so
308 usr/lib64/mesa-9.2.0/libr300.so
20  usr/lib64/mesa-9.2.0/libgalahad.so
16  usr/lib64/mesa-9.2.0/libnoop.so
32  usr/lib64/mesa-9.2.0/librbug.so
60  usr/lib64/mesa-9.2.0/pipe_r300.so
60  usr/lib64/mesa-9.2.0/pipe_radeonsi.so
164 usr/lib64/mesa-9.2.0/egl_gallium.so
152 usr/lib64/mesa-9.2.0/libglapi.so
136 usr/lib64/mesa-9.2.0/libradeonsi.so
16  usr/lib64/mesa-9.2.0/libr300-helper.so
16  usr/lib64/mesa-9.2.0/libidentity.so
8   usr/lib64/mesa-9.2.0/pipe_nouveau.so
184 usr/lib64/mesa-9.2.0/libsvga.so
1888usr/lib64/mesa-9.2.0/libgallium.so
20  usr/lib64/mesa-9.2.0/gbm_gallium_drm.so
1016usr/lib64/mesa-9.2.0/libr600.so
20  usr/lib64/mesa-9.2.0/pipe_vmwgfx.so
3228usr/lib64/mesa-9.2.0/libmesacore.so
152 usr/lib64/mesa-9.2.0/libsoftpipe.so
8   usr/lib64/mesa-9.2.0/pipe_swrast.so
9912usr/lib64/mesa-9.2.0
0   usr/lib64/libOSMesa.so.8
0   usr/lib64/libxatracker.so.1
64  usr/lib64/dri/swrast_dri.so
184 usr/lib64/dri/nouveau_vieux_dri.so
116 usr/lib64/dri/r600_dri.so
288 usr/lib64/dri/radeon_dri.so
876 usr/lib64/dri/i965_dri.so
320 usr/lib64/dri/r200_dri.so
116 usr/lib64/dri/r300_dri.so
120 usr/lib64/dri/radeonsi_dri.so
72  usr/lib64/dri/nouveau_dri.so
4   usr/lib64/dri/updates/README.updates
8   usr/lib64/dri/updates
324 usr/lib64/dri/i915_dri.so
84  usr/lib64/dri/vmwgfx_dri.so
2576usr/lib64/dri
28  usr/lib64/libgbm.so.1.0.0
0   usr/lib64/libGL.so.1
8   usr/lib64/libwayland-egl.so.1.0.0
116 usr/lib64/libxatracker.so.1.0.0
32  usr/lib64/libOSMesa.so.8.0.0
28  usr/lib64/libGLESv1_CM.so.1.1.0
0   usr/lib64/libGLESv2.so.2
112 usr/lib64/vdpau/libvdpau_radeonsi.so.1
112 usr/lib64/vdpau/libvdpau_r300.so.1
68  usr/lib64/vdpau/libvdpau_softpipe.so.1
68  usr/lib64/vdpau/libvdpau_nouveau.so.1
112 usr/lib64/vdpau/libvdpau_r600.so.1
476 usr/lib64/vdpau
32  usr/lib64/libGLESv2.so.2.0.0
0   usr/lib64/libEGL.so.1
36  usr/lib64/libXvMCnouveau.so
0

Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...

2013-09-11 Thread Tom Stellard 
Hi Johannes,

Could explain how you tested these patches:  The configure flags you
used to build as well as the applications/hardware you used for testing.

Thanks,
Tom

On Thu, Sep 12, 2013 at 12:32:38AM +0200, Johannes Obermayr wrote:
 [PATCH 01/21] ilo: Fix out-of-tree build.
 
 [PATCH 02/21] Suppress clang's warnings about unused CFLAGS and CXXFLAGS.
 
 [PATCH 03/21] configure.ac: Save user {C,CXX}FLAGS and append them at end.
 
 [PATCH 04/21] radeon: Build and use libradeon the right way.
   Link libradeon only once in egl-static
 
 [PATCH 05/21] gallium/targets: Make use of prebuilt libdricommon.la.
   Avoid duplicate build.
 
 [PATCH 06/21] Drop support for --enable-static / --disable-shared.
 
 [PATCH 07/21] gallium/auxiliary: Build libgallium shared.
   Hundreds of symbols to be PUBLIC. But saves on a full build
   19 x ~ 1.8 MB.
 
 [PATCH 08/21] Drop last parts of compatibility for the old Mesa build
   I want it to avoid these stupid symlinks while distro build but
   with more work on follow-up patches it should be possible to 
 keep
 
 [PATCH 09/21] mapi: Build libglapi always shared.
   I assume it could be improved later
 
 [PATCH 10/21] mesa: Build libmesa shared.
   Hundreds of PUBLICs but we can get rid of libdricore and get an
   libmesadri which depends as well as libmesagallium on a 
 libmesacore.
   This really speeds up build since duplicate build in libdricore
   with all PUBLIC can be avoided.
   Also dlopen classic drivers should be faster.
 
 [PATCH 11/21] Install all internal shared libs to $(libdir)/mesa-$VERSION.
 
 [PATCH 12/21] Also do it for egl_gallium.so, pipe_*.so and gbm_gallium_drm.
 
 [PATCH 13/21] Makefile.am: s:-no-undefined:-Wl,--no-undefined to make it work.
   libtool will set it back to allow_undefined=yes in 
 func_mode_link ()
   otherwise.
 
 [PATCH 14/21] gallium/drivers: Build libs -shared.
 
 [PATCH 15/21] vdpau,xvmc: Add install-data-hooks to remove unneccessary 
 symlinks.
   libvdpau_*.so.1 and libXvMC*.so libs are dlopened by wrappers.
   Nothing should link them directly.
 
 [PATCH 16/21] glx: Get rid of libglx.la.
 
 [PATCH 17/21] gbm: Get rid of libgbm_dri.la.
 
 [PATCH 18/21] i915: Conditionally build an i915g driver instead of
 
 [PATCH 19/21] freedreno: Make print_sequence a macro to fix clang.
 
 [PATCH 20/21] freedreno: One Makefile.am with a Makefile.sources is
 
 [PATCH 21/21] clover: Force gcc and g++ to fix clang builds.
 
 
 openSUSE x86_64 binary RPMs will look like this:
 $ du -a etc/ usr/
 4   etc/drirc
 8   etc/
 88  usr/lib64/libXvMCr600.so
 140 usr/lib64/libEGL.so.1.0.0
 0   usr/lib64/libGL.so.1.2
 380 usr/lib64/libGL.so.1.2.0
 0   usr/lib64/libGLESv1_CM.so.1
 88  usr/lib64/libXvMCr300.so
 36  usr/lib64/libXvMCsoftpipe.so
 212 usr/lib64/mesa-9.2.0/libllvmpipe.so
 608 usr/lib64/mesa-9.2.0/libmesadri.so
 324 usr/lib64/mesa-9.2.0/libmesagallium.so
 1140usr/lib64/mesa-9.2.0/libnouveau.so
 60  usr/lib64/mesa-9.2.0/libtrace.so
 60  usr/lib64/mesa-9.2.0/pipe_r600.so
 308 usr/lib64/mesa-9.2.0/libr300.so
 20  usr/lib64/mesa-9.2.0/libgalahad.so
 16  usr/lib64/mesa-9.2.0/libnoop.so
 32  usr/lib64/mesa-9.2.0/librbug.so
 60  usr/lib64/mesa-9.2.0/pipe_r300.so
 60  usr/lib64/mesa-9.2.0/pipe_radeonsi.so
 164 usr/lib64/mesa-9.2.0/egl_gallium.so
 152 usr/lib64/mesa-9.2.0/libglapi.so
 136 usr/lib64/mesa-9.2.0/libradeonsi.so
 16  usr/lib64/mesa-9.2.0/libr300-helper.so
 16  usr/lib64/mesa-9.2.0/libidentity.so
 8   usr/lib64/mesa-9.2.0/pipe_nouveau.so
 184 usr/lib64/mesa-9.2.0/libsvga.so
 1888usr/lib64/mesa-9.2.0/libgallium.so
 20  usr/lib64/mesa-9.2.0/gbm_gallium_drm.so
 1016usr/lib64/mesa-9.2.0/libr600.so
 20  usr/lib64/mesa-9.2.0/pipe_vmwgfx.so
 3228usr/lib64/mesa-9.2.0/libmesacore.so
 152 usr/lib64/mesa-9.2.0/libsoftpipe.so
 8   usr/lib64/mesa-9.2.0/pipe_swrast.so
 9912usr/lib64/mesa-9.2.0
 0   usr/lib64/libOSMesa.so.8
 0   usr/lib64/libxatracker.so.1
 64  usr/lib64/dri/swrast_dri.so
 184 usr/lib64/dri/nouveau_vieux_dri.so
 116 usr/lib64/dri/r600_dri.so
 288 usr/lib64/dri/radeon_dri.so
 876 usr/lib64/dri/i965_dri.so
 320 usr/lib64/dri/r200_dri.so
 116 usr/lib64/dri/r300_dri.so
 120 usr/lib64/dri/radeonsi_dri.so
 72  usr/lib64/dri/nouveau_dri.so
 4   usr/lib64/dri/updates/README.updates
 8   usr/lib64/dri/updates
 324 usr/lib64/dri/i915_dri.so
 84  usr/lib64/dri/vmwgfx_dri.so
 2576usr/lib64/dri
 28  usr/lib64/libgbm.so.1.0.0
 0   usr/lib64/libGL.so.1
 8   usr/lib64/libwayland-egl.so.1.0.0
 116 usr/lib64/libxatracker.so.1.0.0
 32  usr/lib64/libOSMesa.so.8.0.0
 28  usr/lib64/libGLESv1_CM.so.1.1.0
 0   usr/lib64/libGLESv2.so.2
 112

Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...

2013-09-11 Thread Marek Olšák 
I don't like this. I prefer to have one big blob for whole Mesa as
discussed on Eric's blog:

http://anholt.livejournal.com/43652.html

I have no problem with longer compile times for release builds if I
get a little bit higher CPU performance with link-time optimizations.
And for debug builds, we can stick to standard -O2 -g or -O0 -g.

Marek

On Thu, Sep 12, 2013 at 12:32 AM, Johannes Obermayr
johannesoberm...@gmx.de wrote:
 [PATCH 01/21] ilo: Fix out-of-tree build.

 [PATCH 02/21] Suppress clang's warnings about unused CFLAGS and CXXFLAGS.

 [PATCH 03/21] configure.ac: Save user {C,CXX}FLAGS and append them at end.

 [PATCH 04/21] radeon: Build and use libradeon the right way.
   Link libradeon only once in egl-static

 [PATCH 05/21] gallium/targets: Make use of prebuilt libdricommon.la.
   Avoid duplicate build.

 [PATCH 06/21] Drop support for --enable-static / --disable-shared.

 [PATCH 07/21] gallium/auxiliary: Build libgallium shared.
   Hundreds of symbols to be PUBLIC. But saves on a full build
   19 x ~ 1.8 MB.

 [PATCH 08/21] Drop last parts of compatibility for the old Mesa build
   I want it to avoid these stupid symlinks while distro build but
   with more work on follow-up patches it should be possible to 
 keep

 [PATCH 09/21] mapi: Build libglapi always shared.
   I assume it could be improved later

 [PATCH 10/21] mesa: Build libmesa shared.
   Hundreds of PUBLICs but we can get rid of libdricore and get an
   libmesadri which depends as well as libmesagallium on a 
 libmesacore.
   This really speeds up build since duplicate build in libdricore
   with all PUBLIC can be avoided.
   Also dlopen classic drivers should be faster.

 [PATCH 11/21] Install all internal shared libs to $(libdir)/mesa-$VERSION.

 [PATCH 12/21] Also do it for egl_gallium.so, pipe_*.so and gbm_gallium_drm.

 [PATCH 13/21] Makefile.am: s:-no-undefined:-Wl,--no-undefined to make it work.
   libtool will set it back to allow_undefined=yes in 
 func_mode_link ()
   otherwise.

 [PATCH 14/21] gallium/drivers: Build libs -shared.

 [PATCH 15/21] vdpau,xvmc: Add install-data-hooks to remove unneccessary 
 symlinks.
   libvdpau_*.so.1 and libXvMC*.so libs are dlopened by wrappers.
   Nothing should link them directly.

 [PATCH 16/21] glx: Get rid of libglx.la.

 [PATCH 17/21] gbm: Get rid of libgbm_dri.la.

 [PATCH 18/21] i915: Conditionally build an i915g driver instead of

 [PATCH 19/21] freedreno: Make print_sequence a macro to fix clang.

 [PATCH 20/21] freedreno: One Makefile.am with a Makefile.sources is

 [PATCH 21/21] clover: Force gcc and g++ to fix clang builds.


 openSUSE x86_64 binary RPMs will look like this:
 $ du -a etc/ usr/
 4   etc/drirc
 8   etc/
 88  usr/lib64/libXvMCr600.so
 140 usr/lib64/libEGL.so.1.0.0
 0   usr/lib64/libGL.so.1.2
 380 usr/lib64/libGL.so.1.2.0
 0   usr/lib64/libGLESv1_CM.so.1
 88  usr/lib64/libXvMCr300.so
 36  usr/lib64/libXvMCsoftpipe.so
 212 usr/lib64/mesa-9.2.0/libllvmpipe.so
 608 usr/lib64/mesa-9.2.0/libmesadri.so
 324 usr/lib64/mesa-9.2.0/libmesagallium.so
 1140usr/lib64/mesa-9.2.0/libnouveau.so
 60  usr/lib64/mesa-9.2.0/libtrace.so
 60  usr/lib64/mesa-9.2.0/pipe_r600.so
 308 usr/lib64/mesa-9.2.0/libr300.so
 20  usr/lib64/mesa-9.2.0/libgalahad.so
 16  usr/lib64/mesa-9.2.0/libnoop.so
 32  usr/lib64/mesa-9.2.0/librbug.so
 60  usr/lib64/mesa-9.2.0/pipe_r300.so
 60  usr/lib64/mesa-9.2.0/pipe_radeonsi.so
 164 usr/lib64/mesa-9.2.0/egl_gallium.so
 152 usr/lib64/mesa-9.2.0/libglapi.so
 136 usr/lib64/mesa-9.2.0/libradeonsi.so
 16  usr/lib64/mesa-9.2.0/libr300-helper.so
 16  usr/lib64/mesa-9.2.0/libidentity.so
 8   usr/lib64/mesa-9.2.0/pipe_nouveau.so
 184 usr/lib64/mesa-9.2.0/libsvga.so
 1888usr/lib64/mesa-9.2.0/libgallium.so
 20  usr/lib64/mesa-9.2.0/gbm_gallium_drm.so
 1016usr/lib64/mesa-9.2.0/libr600.so
 20  usr/lib64/mesa-9.2.0/pipe_vmwgfx.so
 3228usr/lib64/mesa-9.2.0/libmesacore.so
 152 usr/lib64/mesa-9.2.0/libsoftpipe.so
 8   usr/lib64/mesa-9.2.0/pipe_swrast.so
 9912usr/lib64/mesa-9.2.0
 0   usr/lib64/libOSMesa.so.8
 0   usr/lib64/libxatracker.so.1
 64  usr/lib64/dri/swrast_dri.so
 184 usr/lib64/dri/nouveau_vieux_dri.so
 116 usr/lib64/dri/r600_dri.so
 288 usr/lib64/dri/radeon_dri.so
 876 usr/lib64/dri/i965_dri.so
 320 usr/lib64/dri/r200_dri.so
 116 usr/lib64/dri/r300_dri.so
 120 usr/lib64/dri/radeonsi_dri.so
 72  usr/lib64/dri/nouveau_dri.so
 4   usr/lib64/dri/updates/README.updates
 8   usr/lib64/dri/updates
 324 usr/lib64/dri/i915_dri.so
 84  usr/lib64/dri/vmwgfx_dri.so
 2576usr/lib64/dri
 28  usr/lib64/libgbm.so.1.0.0
 0   usr/lib64/libGL.so.1
 8

Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...

2013-09-11 Thread Marek Olšák 
BTW, the build system fixes would be good to have anyway, but I'm not
an expert on the Mesa build system.

Marek

On Thu, Sep 12, 2013 at 1:51 AM, Marek Olšák mar...@gmail.com wrote:
 I don't like this. I prefer to have one big blob for whole Mesa as
 discussed on Eric's blog:

 http://anholt.livejournal.com/43652.html

 I have no problem with longer compile times for release builds if I
 get a little bit higher CPU performance with link-time optimizations.
 And for debug builds, we can stick to standard -O2 -g or -O0 -g.

 Marek

 On Thu, Sep 12, 2013 at 12:32 AM, Johannes Obermayr
 johannesoberm...@gmx.de wrote:
 [PATCH 01/21] ilo: Fix out-of-tree build.

 [PATCH 02/21] Suppress clang's warnings about unused CFLAGS and CXXFLAGS.

 [PATCH 03/21] configure.ac: Save user {C,CXX}FLAGS and append them at end.

 [PATCH 04/21] radeon: Build and use libradeon the right way.
   Link libradeon only once in egl-static

 [PATCH 05/21] gallium/targets: Make use of prebuilt libdricommon.la.
   Avoid duplicate build.

 [PATCH 06/21] Drop support for --enable-static / --disable-shared.

 [PATCH 07/21] gallium/auxiliary: Build libgallium shared.
   Hundreds of symbols to be PUBLIC. But saves on a full build
   19 x ~ 1.8 MB.

 [PATCH 08/21] Drop last parts of compatibility for the old Mesa build
   I want it to avoid these stupid symlinks while distro build but
   with more work on follow-up patches it should be possible to 
 keep

 [PATCH 09/21] mapi: Build libglapi always shared.
   I assume it could be improved later

 [PATCH 10/21] mesa: Build libmesa shared.
   Hundreds of PUBLICs but we can get rid of libdricore and get an
   libmesadri which depends as well as libmesagallium on a 
 libmesacore.
   This really speeds up build since duplicate build in libdricore
   with all PUBLIC can be avoided.
   Also dlopen classic drivers should be faster.

 [PATCH 11/21] Install all internal shared libs to $(libdir)/mesa-$VERSION.

 [PATCH 12/21] Also do it for egl_gallium.so, pipe_*.so and gbm_gallium_drm.

 [PATCH 13/21] Makefile.am: s:-no-undefined:-Wl,--no-undefined to make it 
 work.
   libtool will set it back to allow_undefined=yes in 
 func_mode_link ()
   otherwise.

 [PATCH 14/21] gallium/drivers: Build libs -shared.

 [PATCH 15/21] vdpau,xvmc: Add install-data-hooks to remove unneccessary 
 symlinks.
   libvdpau_*.so.1 and libXvMC*.so libs are dlopened by wrappers.
   Nothing should link them directly.

 [PATCH 16/21] glx: Get rid of libglx.la.

 [PATCH 17/21] gbm: Get rid of libgbm_dri.la.

 [PATCH 18/21] i915: Conditionally build an i915g driver instead of

 [PATCH 19/21] freedreno: Make print_sequence a macro to fix clang.

 [PATCH 20/21] freedreno: One Makefile.am with a Makefile.sources is

 [PATCH 21/21] clover: Force gcc and g++ to fix clang builds.


 openSUSE x86_64 binary RPMs will look like this:
 $ du -a etc/ usr/
 4   etc/drirc
 8   etc/
 88  usr/lib64/libXvMCr600.so
 140 usr/lib64/libEGL.so.1.0.0
 0   usr/lib64/libGL.so.1.2
 380 usr/lib64/libGL.so.1.2.0
 0   usr/lib64/libGLESv1_CM.so.1
 88  usr/lib64/libXvMCr300.so
 36  usr/lib64/libXvMCsoftpipe.so
 212 usr/lib64/mesa-9.2.0/libllvmpipe.so
 608 usr/lib64/mesa-9.2.0/libmesadri.so
 324 usr/lib64/mesa-9.2.0/libmesagallium.so
 1140usr/lib64/mesa-9.2.0/libnouveau.so
 60  usr/lib64/mesa-9.2.0/libtrace.so
 60  usr/lib64/mesa-9.2.0/pipe_r600.so
 308 usr/lib64/mesa-9.2.0/libr300.so
 20  usr/lib64/mesa-9.2.0/libgalahad.so
 16  usr/lib64/mesa-9.2.0/libnoop.so
 32  usr/lib64/mesa-9.2.0/librbug.so
 60  usr/lib64/mesa-9.2.0/pipe_r300.so
 60  usr/lib64/mesa-9.2.0/pipe_radeonsi.so
 164 usr/lib64/mesa-9.2.0/egl_gallium.so
 152 usr/lib64/mesa-9.2.0/libglapi.so
 136 usr/lib64/mesa-9.2.0/libradeonsi.so
 16  usr/lib64/mesa-9.2.0/libr300-helper.so
 16  usr/lib64/mesa-9.2.0/libidentity.so
 8   usr/lib64/mesa-9.2.0/pipe_nouveau.so
 184 usr/lib64/mesa-9.2.0/libsvga.so
 1888usr/lib64/mesa-9.2.0/libgallium.so
 20  usr/lib64/mesa-9.2.0/gbm_gallium_drm.so
 1016usr/lib64/mesa-9.2.0/libr600.so
 20  usr/lib64/mesa-9.2.0/pipe_vmwgfx.so
 3228usr/lib64/mesa-9.2.0/libmesacore.so
 152 usr/lib64/mesa-9.2.0/libsoftpipe.so
 8   usr/lib64/mesa-9.2.0/pipe_swrast.so
 9912usr/lib64/mesa-9.2.0
 0   usr/lib64/libOSMesa.so.8
 0   usr/lib64/libxatracker.so.1
 64  usr/lib64/dri/swrast_dri.so
 184 usr/lib64/dri/nouveau_vieux_dri.so
 116 usr/lib64/dri/r600_dri.so
 288 usr/lib64/dri/radeon_dri.so
 876 usr/lib64/dri/i965_dri.so
 320 usr/lib64/dri/r200_dri.so
 116 usr/lib64/dri/r300_dri.so
 120 usr/lib64/dri/radeonsi_dri.so
 72  usr/lib64/dri/nouveau_dri.so
 4   usr/lib64/dri/updates/README.updates
 8   usr/lib64/dri/updates

Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...

2013-09-11 Thread Johannes Obermayr 
I am preferring a full build:
../configure --libdir=/usr/lib64 --includedir=/usr/include --bindir=/usr/bin 
--prefix=/usr --sysconfdir=/etc --enable-xvmc --enable-vdpau 
--enable-texture-float --enable-debug 
--with-dri-drivers=i915,i965,nouveau,r200,radeon,swrast 
--with-gallium-drivers=freedreno,i915,ilo,nouveau,r300,r600,radeonsi,svga,swrast
 --enable-dri --enable-glx --enable-osmesa --enable-gles1 --enable-gles2 
--enable-openvg --enable-gbm --enable-xa --enable-gallium-egl 
--enable-gallium-llvm --enable-gallium-gbm --enable-r600-llvm-compiler 
--enable-opencl --enable-gallium-g3dvl --enable-glx-tls

Most of other build tests were done by aboll - kudo to Andreas for this.

Required libs and PUBLICs were detected in hundreds of builds - you don't 
believe but linkers want to play and don't report all missing symbols in one 
library at once ;)

My last was --enable-osmesa --with-dri-drivers= --with-gallium-drivers=...:
I decided not to build additionally the required libmesadri for this but use a 
fallback to the more reasonable --enable-osmesa-gallium which uses 
libmesagallium (see in [PATCH 10/21]).

I have used/tested them heavily on nouveau (Nvidia ION), r600 (AMD Fusion) and 
r200 (Mobility Radeon 9000) for a longer time. I bet also other 
hardware/drivers will not make problems.
IMHO it is not a change in functionality but a rightsizing of existing code.

Maybe it is an already-to-use alternative to megadrivers project. Sorry Eric 
but your LiveJournal message inspired me to hurry up! ;)

Johannes

Am Mittwoch, 11. September 2013, 16:01:55 schrieb Tom Stellard:
 Hi Johannes,
 
 Could explain how you tested these patches:  The configure flags you
 used to build as well as the applications/hardware you used for testing.
 
 Thanks,
 Tom
 
 On Thu, Sep 12, 2013 at 12:32:38AM +0200, Johannes Obermayr wrote:
  [PATCH 01/21] ilo: Fix out-of-tree build.
  
  [PATCH 02/21] Suppress clang's warnings about unused CFLAGS and CXXFLAGS.
  
  [PATCH 03/21] configure.ac: Save user {C,CXX}FLAGS and append them at end.
  
  [PATCH 04/21] radeon: Build and use libradeon the right way.
Link libradeon only once in egl-static
  
  [PATCH 05/21] gallium/targets: Make use of prebuilt libdricommon.la.
Avoid duplicate build.
  
  [PATCH 06/21] Drop support for --enable-static / --disable-shared.
  
  [PATCH 07/21] gallium/auxiliary: Build libgallium shared.
Hundreds of symbols to be PUBLIC. But saves on a full build
19 x ~ 1.8 MB.
  
  [PATCH 08/21] Drop last parts of compatibility for the old Mesa build
I want it to avoid these stupid symlinks while distro build 
  but
with more work on follow-up patches it should be possible to 
  keep
  
  [PATCH 09/21] mapi: Build libglapi always shared.
I assume it could be improved later
  
  [PATCH 10/21] mesa: Build libmesa shared.
Hundreds of PUBLICs but we can get rid of libdricore and get 
  an
libmesadri which depends as well as libmesagallium on a 
  libmesacore.
This really speeds up build since duplicate build in 
  libdricore
with all PUBLIC can be avoided.
Also dlopen classic drivers should be faster.
  
  [PATCH 11/21] Install all internal shared libs to $(libdir)/mesa-$VERSION.
  
  [PATCH 12/21] Also do it for egl_gallium.so, pipe_*.so and gbm_gallium_drm.
  
  [PATCH 13/21] Makefile.am: s:-no-undefined:-Wl,--no-undefined to make it 
  work.
libtool will set it back to allow_undefined=yes in 
  func_mode_link ()
otherwise.
  
  [PATCH 14/21] gallium/drivers: Build libs -shared.
  
  [PATCH 15/21] vdpau,xvmc: Add install-data-hooks to remove unneccessary 
  symlinks.
libvdpau_*.so.1 and libXvMC*.so libs are dlopened by wrappers.
Nothing should link them directly.
  
  [PATCH 16/21] glx: Get rid of libglx.la.
  
  [PATCH 17/21] gbm: Get rid of libgbm_dri.la.
  
  [PATCH 18/21] i915: Conditionally build an i915g driver instead of
  
  [PATCH 19/21] freedreno: Make print_sequence a macro to fix clang.
  
  [PATCH 20/21] freedreno: One Makefile.am with a Makefile.sources is
  
  [PATCH 21/21] clover: Force gcc and g++ to fix clang builds.
  
  
  openSUSE x86_64 binary RPMs will look like this:
  $ du -a etc/ usr/
  4   etc/drirc
  8   etc/
  88  usr/lib64/libXvMCr600.so
  140 usr/lib64/libEGL.so.1.0.0
  0   usr/lib64/libGL.so.1.2
  380 usr/lib64/libGL.so.1.2.0
  0   usr/lib64/libGLESv1_CM.so.1
  88  usr/lib64/libXvMCr300.so
  36  usr/lib64/libXvMCsoftpipe.so
  212 usr/lib64/mesa-9.2.0/libllvmpipe.so
  608 usr/lib64/mesa-9.2.0/libmesadri.so
  324 usr/lib64/mesa-9.2.0/libmesagallium.so
  1140usr/lib64/mesa-9.2.0/libnouveau.so
  60  usr/lib64/mesa-9.2.0/libtrace.so
  60  usr/lib64/mesa-9.2.0/pipe_r600.so
  308 usr/lib64/mesa-9.2.0/libr300.so
  20