[Mesa-dev] forking shared intel directory?

Kenneth Graunke kenneth at whitecape.org
Fri Jun 21 22:09:27 PDT 2013


On 06/21/2013 11:29 AM, Eric Anholt wrote:
> Long ago, when porting FBO and memory management support to i965, I
> merged a bunch of code between the i915 and i965 drivers and put it in
> the intel directory.  I think it served us well for a long time, as both
> drivers got improvements from shared work on that code.  But since then,
> we've talked several times about splitting things back apart (since we
> break i915 much more often than we improve it), so I spent yesterday and
> today looking at what the impact would be.
>
> LOC counts (wc -l):
>
>              intel/     i915/       i965/         total
> master:     14751      13458       61109         89318
> fork-i915:  0          24322       74978         99300
>
> We duplicate ~10000 lines of code, but i915 drops ~4000 lines of code
>  From its build and i965 drops ~1000.
>
> context size:
>                 i915        i965
> master:        99512       101456
> fork-i915:     99384       100824
>
> There's a bunch of cleanup I haven't done in the branch, like moving
> brw_vtbl.c contents to sensible places, or nuking the intel vs brw split
> that doesn't make any sense any more.
>
> I'm ambivalent about the change.  If the code growth from splitting was
> <7000 lines or so, I'd be happy, but this feels pretty big.  On the
> other hand, the cleanups feel good to me.

I'm still in favor of this - you've already embarked on some good 
tidying, and there's much more that can be done.  I think in the end, 
both drivers will be better off.  I'd also feel better if it were < 
7000, but at some point it makes sense anyway.

I do think the duplicated code may diverge further in the future (say, 
due to new Gen4+ only acceleration paths or improved implementations of 
things), and that there's a bit more that could be cut/coalesced.

> I don't know how other
> developers feel.  There's a branch up at fork-i915 of my tree.  If
> people are excited about doing this and I get a bunch of acks for the
> two "copy the code to my directory" commits, I'll do those two then
> start sending out the non-copying changes for review.  If people don't
> like it, I won't be hurt.

That sounds like a good plan to me.  I'd be happy to do some post-fork 
tidying, but I'd much rather get your code landed before embarking too 
far on that path.

What do others think?


More information about the mesa-dev mailing list