On 06/04/2020 17:27, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-04-06 15:07:30)
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?
Yes. And can be done so only by changing the context setup to create one
context with two independent rcs engines (different logical GPU state,
and rings, *only* sharing the same vm). And since legacy EXEC_DEFAULT[0]
and EXEC_RENDER[1] alias to the same engine, very little code needs to be
changed to support (1 ctx, 2 engines) vs (2 ctx, 1 engine).
-Chris
Sounds like there could a performance gain somewhere...
Will look into this.
-Lionel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
