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? _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
