So I'm not going to go into technical detail here, which I'll happily leave to Joonas et al, but I think a couple of general points deserve to be addressed. On Tue, 26 Feb 2019, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen > <joonas.lahtinen@xxxxxxxxxxxxxxx> wrote: >> Adding the suggested smaller amount of code vs. doing a much bigger >> rewrite is something of a straightforward choice with the amount of >> platforms and features in flight, especially when the end result is >> the same. > > Because you will probably never do it. It's almost always easier to > just incrementally add on to existing code. One could argue that GEM > evolved into more or less the exact same thing as TTM anyway so why > not bite the bullet and switch at some point? TTM works fine even for > UMA hardware. Surely we have lots of faults, but being averse to refactoring, reworking, and continuously rewriting parts of the driver is not among them by any stretch. Sometimes it's just for the general maintainability, sometimes to remodel stuff to neatly plug in support for that new piece of hardware, and everything in between. > There is a common misconception in big companies that if you utilize > shared infrastructure it will slow you down or you'll lose control of > your code which is I think what you are referring to. Ultimately, it > does sometimes raise the bar, but in the long term it benefits > everyone and usually it doesn't really add that much overhead. It > sounds like you are just feeding that misconception; you can't > contribute to or take advantage of any shared infrastructure because > that might slow you down. If that is the case, then why does upstream > first even matter? It seems like the only common code you want to > support is common code that you wrote in the first place. Again, on a general note, without actually checking the stats, I like to think we're pretty good citizens wrt actively using and contributing to shared infrastructure, and shared uapi. Especially so for KMS, and even when it really has slowed us down. So while you may have fair points about a specific case, and again I'll let Joonas address the specific case, I'll have to ask you to please not generalize that to the whole driver. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
