[Intel-gfx] [PATCH 24/50] drm/i915: Allow userspace to clone contexts on creation

Chris Wilson chris at chris-wilson.co.uk
Wed Apr 17 07:53:32 UTC 2019


Quoting Tvrtko Ursulin (2019-04-15 13:56:10)
> 
> On 12/04/2019 09:53, Chris Wilson wrote:
> > +struct drm_i915_gem_context_create_ext_clone {
> > +#define I915_CONTEXT_CREATE_EXT_CLONE 1
> > +     struct i915_user_extension base;
> > +     __u32 clone_id;
> > +     __u32 flags;
> > +#define I915_CONTEXT_CLONE_ENGINES   (1u << 0)
> > +#define I915_CONTEXT_CLONE_FLAGS     (1u << 1)
> > +#define I915_CONTEXT_CLONE_SCHEDATTR (1u << 2)
> > +#define I915_CONTEXT_CLONE_SSEU              (1u << 3)
> > +#define I915_CONTEXT_CLONE_TIMELINE  (1u << 4)
> > +#define I915_CONTEXT_CLONE_VM                (1u << 5)
> > +#define I915_CONTEXT_CLONE_UNKNOWN -(I915_CONTEXT_CLONE_VM << 1)
> 
> Have we talked about whether CLONE_UNKNOWN makes sense or instead we say 
> "-1" is CLONE_EVERYTHING? Currently the latter sounds more usable and 
> easier to maintain in userspace to me.

We haven't talked. I went for you have to opt in explicitly for the bits
you want cloned so that when we extend it in future, old userspace
suddenly doesn't start sharing more than they were previously.
Oversharing, I felt, was an accident waiting to happen.

Now you can argue that if they simply use ~CLONE_UNKNOWN they get
exactly the same change if they recompile... But old binaries retain
their existing behaviour if the interface changes.
-Chris


More information about the Intel-gfx mailing list