Re: [PATCH 02/13] drm/i915: Introduce the i915_user_extension_method

[Chris Wilson <chris@chris-wilson.co.uk>]

Quoting Tvrtko Ursulin (2019-03-13 13:11:09)
> 
> On 13/03/2019 11:46, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-03-13 11:35:55)
> > [snip]
> >> Shall we only reserve some space with a flags and some rsvd fields just
> >> in case it will need to change/grow?
> > 
> > The only thing that occurs to me is to exchange the next pointer with a
> > table of next[] (C++ here we come). But I ask myself, could any
> > extension like not be part of the next layer?
> > 
> > That is if any particular extension needs to chain up to more than one
> > iface, it can call each itself:
> > 
> > struct hypothetical_extension {
> >       struct i915_user_extension base;
> > 
> >       u64 iface1_extension;
> >       u64 iface2_extension;
> >       ...
> >       u64 ifaceN_extension;
> > }
> > 
> > ? So far I haven't thought of anything I can't weasel my way out by
> > punting the problem to the caller :)
> 
> Just top make sure we are on the same page, I was thinking of:
> 
> struct i915_user_extension {
>         __u64 next_extension;
>         __u64 name;
>         __u32 flags;
>         __u32 rsvd[7];
> };
> 
> So we could add things like:
> 
> /* Store each extension return code in rsvd[0]. */
> #define I915_USER_EXTENSION_STORE_RESULT (1)
> 
> /* Only check whether extensions are known by the driver. */
> #define I915_USER_EXTENSION_DRY_RUN. (2)
> 
> And things like that. Because we are putting in a generic extension 
> mechanism I am worried that if it itself turns out to have some 
> limitation we will not have wiggle room to extend it.

u64 next;
u32 name;
u32 flags;
u32 rsvd[4];

Maybe... That's a cacheline.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx