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@xxxxxxxxx>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
