On 01/03/2019 19:10, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-01 16:36:45)
On 01/03/2019 14:03, Chris Wilson wrote:
It can be useful to have a single ioctl to create a context with all
the initial parameters instead of a series of create + setparam + setparam
ioctls. This extension to create context allows any of the parameters
to be passed in as a linked list to be applied to the newly constructed
context.
v2: Make a local copy of user setparam (Tvrtko)
v3: Use flags to detect availability of extension interface
Looks good to me.
Why have you changed to use flags and not just check the extension field
being non-null?
Hmm. I was thinking about how new userspace would use it on an old kernel.
As the extension is in a new bit of the extension struct that won't be
passed to the old ioctl, and so it would create a context and not report
any error despite not processing the extensions (userspace would be none
the wiser that the context was invalid). So a simple answer was to use
the flags field to indicate that we want the extension processed; the
old kernel would reject the ioctl due to pad!=0, a new kernel will be
happy. New userspace on old kernel can then fallback gracefully.
+uint32_t
+brw_clone_hw_context(struct brw_bufmgr *bufmgr, uint32_t ctx_id)
+{
+ struct drm_i915_gem_context_create_ext_clone ext_clone = {
+ .base = { I915_CONTEXT_CREATE_EXT_CLONE },
+ .clone = ctx_id,
+ .flags = ~I915_CONTEXT_CLONE_UNKNOWN,
+ };
+ struct drm_i915_gem_context_create_ext arg = {
+ .flags = I915_CONTEXT_CREATE_USE_EXTENSIONS,
+ .extensions = (uintptr_t)&ext_clone
+ };
+ if (drmIoctl(bufmgr->fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, &arg) == 0)
+ return arg.ctx_id;
+
+ return __brw_clone_hw_context(bufmgr, ctx_id);
+}
Yeah, makes sense.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
