[Intel-gfx] [PATCH 0/2] introduce derefenrencing helpers
airlied at gmail.com
Wed Mar 17 16:34:33 PDT 2010
On Thu, Mar 18, 2010 at 7:45 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Wed, Mar 17, 2010 at 02:15:26PM -0700, Eric Anholt wrote:
>> On Mon, 8 Mar 2010 13:35:01 +0100, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
>> Informal review on IRC was "wow, that's a lot of churn. Does it do
>> something useful?"
>> Certainly the dev_priv one makes the intel driver look different from
>> all other drivers, and I don't think in a good way. If we had a record
>> of getting types mixed up, the type safety might make a good argument,
>> but when you just copy and paste the line for the lookup every time
> Well, type-safety was not the goal of these ... I've intended to make
> drm_gem_object subclassable (i.e. obj_priv.base instead of obj_priv->obj).
I'd like to subscribe to your newsletter.
I meant to do this back at the start of GEM and I really wished I'd
one it then, so
its a Yay from me.
> This should
> - save a few bytes and at least one cachelines (the drm bo is no longer somewhere
> totally different).
> - save the need to carry around two pointers per bo (x86-32 has only 4
> truely usable registers ...).
> And therefore hopefully make execbuf go faster. The dev_priv was more or
> less just a corollary. I've various stages of this lying around but never
> really managed to complete & benchmark it. But know that this dreaded i8xx
> cache coherency problem is finally making progress (at least here) I plan
> to tackle this idea for real.
> Daniel Vetter
> Mail: daniel at ffwll.ch
> Mobile: +41 (0)79 365 57 48
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
More information about the Intel-gfx