[Mesa-dev] megadrivers series
eric at anholt.net
Wed Oct 2 12:47:48 PDT 2013
Emil Velikov <emil.l.velikov at gmail.com> 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
>> video from the talk I gave at XDC:
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 835 bytes
Desc: not available
More information about the mesa-dev