[Intel-gfx] [PATCH 24/50] drm/i915: Allow userspace to clone contexts on creation
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Wed Apr 17 08:03:32 UTC 2019
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 at intel.com>
Regards,
Tvrtko
More information about the Intel-gfx
mailing list