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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
