Re: [RFC 3/5] drm/i915: Infrastructure for supporting different GGTT views per object

From: Daniel Vetter <daniel@ffwll.ch>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx <Intel-gfx@lists.freedesktop.org>
Subject: Re: [RFC 3/5] drm/i915: Infrastructure for supporting different GGTT views per object
Date: Mon, 3 Nov 2014 18:35:06 +0100	[thread overview]
Message-ID: <CAKMK7uHkvt2e6Ur71HEcFHcTwDTyLfww4hMAZgbns2ip9_y5zQ@mail.gmail.com> (raw)
In-Reply-To: <5457B957.6070102@linux.intel.com>

On Mon, Nov 3, 2014 at 6:20 PM, Tvrtko Ursulin
<tvrtko.ursulin@linux.intel.com> wrote:
>> I'm not a fan of preemptive generalization - it tends to be the wrong one
>> and hurt doubly in the future since you have to remove the wrong one first
>> before you can add the right stuff.
>
>
> In general :), as always it is the question of getting the balance right.
> Because the opposite can also happen and maybe even has in some parts of the
> driver.

Well there are ugly corners, but generally just areas where the proper
abstraction wasn't yet clear. Or areas where we've never gotten around
to implement what we discussed we wanted. The few cases where we've
had overgeneralization tended to hurt us badly and actually the
reasons behind some of the cruft in GEM.

> Anyway, that's why I didn't bother with polishing the enums etc. :)

Well I think if we do add some new abstraction it should be polished.
The point of abstraction is to hide details, and that's only possible
if the abstraction is clean&polished and doesn't leak in any
direction. Given that I've mastered in advanced abstract nonsene (i.e.
math) I might have a bit a screwed view here ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx