[Mesa-dev] forking shared intel directory?

[Chad Versace]

On 06/21/2013 10:09 PM, Kenneth Graunke wrote:
> 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?

I'm in favor of the fork. I think that the resultant code will be easier to
work with and easier to understand.

Also, since I came into Mesa during the Sandybridge era, I'm completely
unfamiliar with the i915 code. I sometimes encounter codepaths in the intel
directory that smells like i915 code, but I'm unsure if it actually is, having
never worked on that driver. So I cautiously tiptoe around the code lest I
break i915. I look forward to eliminating that need to cautiously tiptoe.