[Intel-gfx] [PATCH v2 3/3] drm/i915/perf: enable filtering on multiple contexts
Lionel Landwerlin
lionel.g.landwerlin at intel.com
Mon Apr 6 14:07:30 UTC 2020
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
More information about the Intel-gfx
mailing list