Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...
On Thu, Sep 12, 2013 at 3:32 PM, Christian König wrote: > 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. The version file is the only way not to export LLVM symbols as far as I know, so I'm afraid I can't get rid of it. Marek ___ 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 ...
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
Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...
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 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 ...
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 > 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 ...
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 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 ...
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 ...
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 ...
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 ...
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 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 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
Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...
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/lib
Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...
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 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 > 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/r20
Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...
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 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 >
Re: [Mesa-dev] The long way to a faster build with shared libs and some fixes ...
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