On 06/04/2020 16:59, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-04-06 14:54:38)
On 31/03/2020 21:08, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-03-31 12:48:21)
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
Hmm. The other thought is ctx->engine[] where one context may have more
than one logical context instance that OA could track. The extension to
track multiple pinned contexts should equally work for multiple engines.
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 64) = {};
struct drm_i915_gem_context_param p = {
.ctx_id = gem_context_create(i915),
.param = I915_CONTEXT_PARAM_ENGINES,
.value = to_user_pointer(&engines),
.size = sizeof(struct i915_context_param_engines),
};
gem_context_set_param(i915, &p);
would do the trick in creating one context with 64 rcs0 that they may
want to track. And that also opens the door to virtual engines over top.
-Chris
I rather punt this away for now :)
I can't see use cases for Iris/Vulkan.
There's immediate use cases for iris, since it uses 2 contexts instead
of 2 logical instances within one GL/GEM context.
I don't understand this. Are you saying Iris could use the stuff from
above and still select what logical context to dispatch to?
It really wants to pin a given logical context to particular set of
commands.
-Lionel
The changes you have here trivially accommodate supporting user defined
engines[], it seems a waste not to.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
