Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)

[Jani Nikula <jani.nikula@linux.intel.com>]

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@gmail.com> wrote:
> On Mon, Feb 25, 2019 at 9:35 PM Joonas Lahtinen
> <joonas.lahtinen@linux.intel.com> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel