[Mesa-dev] forking shared intel directory?
chad.versace at linux.intel.com
Wed Jun 26 09:47:13 PDT 2013
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.
More information about the mesa-dev