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

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 17/04/2019 08:53, Chris Wilson wrote:
> 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.

The thing I was thinking about was if context gets some new functional 
category which can be cloned, but old binaries would therefore not clone 
it and as such end up as non-functional or degraded context. I don't 
have an example in mind so just hypothetical.

I went to remind myself what clone(2) does and it matches your idea. So 
that makes sense.

We just have to keep in mind not to add a new category which makes the 
cloned context has surprising behaviour.

Patch did look fine so:

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx