[Mesa-dev] megadrivers series

[Eric Anholt]

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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131002/0b122eb5/attachment.pgp>