[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