Emil Velikov <[email protected]> writes: > On 30/09/13 21:44, Eric Anholt wrote: >> Here are the megadrivers changes, after the prep series I posted earlier. >> A few tiny updates to the prep series are available in my tree as >> "megadriver-prep" and this series is available as "megadrivers-5" >> >> FPS improvement on GLB2.7 with INTEL_NO_HW=1: 2.61061% +/- 1.16957% (n=50) >> >> One question I have is whether the hardlinks are going to cause problems >> for packaging. I noticed that when I went and stripped the binaries >> trying to do a space comparison, I of course got brand new inodes each >> taking up their own set of disk space. I do really like how hardlinks end >> up for installing on my test systems a single binary I can move around >> however I need. >> > Great work Eric :) > > A couple of trivial ones (apart from patch 8 and 13) > > * IMHO you safely drop "dridir" from nouveau, radeon, r200, i915 's > Makefile.am. It's already set in src/mesa/drivers/dri/Makefile.am
Oh, yeah. I definitely liked how much little we ended up with in the per-driver Makefile.am's there, and more reduction is great. > * Can you please leave a comment in code, wrt the i915/radeon header > reshuffle ? Not sure quite what you're asking for here -- not just the comment above the #defines? >> video from the talk I gave at XDC: >> http://www.youtube.com/watch?v=0fJq-2haT3Y >> > As a follow up to a question from XDC, size of st/dri wrt the driver > itself here are some numbers that give can give you a rough idea. > > Release build with debug symbols > [323K] libdricommon.a > [424K] libdridrm.a > [ 12M] libgallium.a > [ 47M] libmesagallium.a > [ 25M] libnouveau.a > [ 52K] libnouveaudrm.a > [408K] librbug.a > [619K] libtrace.a > [ 36M] nouveau_dri.so > > Release build without debug symbols > [ 51K] libdricommon.a > [ 48K] libdridrm.a > [2.4M] libgallium.a > [5.3M] libmesagallium.a > [2.1M] libnouveau.a > [2.0K] libnouveaudrm.a > [ 41K] librbug.a > [147K] libtrace.a > [6.1M] nouveau_dri.so Ultimately, the only size we care about as far as justifying dricore/megadrivers' existence is the sum of the size of the installed files. Cutting size of build byproducts, if we manage to, is just a minor win for developers. >> I think Emil has been looking at doing the gallium side of things, so I >> haven't pushed forward with that. >> > Initially I got over-exited over the idea until I realized that gallium > does not use/build libdricore :) > > I'm planning to have something by the end of the week (just got my final > year project at Uni), although my plan is to leave it optional. Any > suggestions/preferences ? Maintaining build options is work, and it means that people get the wrong thing or developers end up breaking options they aren't testing. That's why we removed non-dricore before.
pgpLiQ6BAiRIG.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
