[Intel-gfx] [PATCH v6 3/3] drm/i915: Predictive governor to control slice/subslice/eu
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Tue Nov 26 11:31:14 UTC 2019
On 26/11/2019 11:09, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-11-26 10:51:22)
>> You mentioned you did some experiment where you did something on context
>> pinning and that it did not work so well. I don't know what that was
>> though. I don't think that was ever posted?
>>
>> What I am thinking is this: You drop the timer altogether. Instead in
>> __execlists_update_reg_state you look at your gem_context->req_cnt and
>> implement your logic there.
>
> I noticed the same non-sequitur. Except I would push that either the
> entire measurement and hence patch series is bogus (beyond the patches
> themselves being trivially broken, tested much?), or that it really
> should be done from a timer and also adjust pinned contexts ala
> reconfigure_sseu.
Yeah, if doing it at pin time would not show the power benefit that
would mean looking at req_cnt at pin time does not work, while looking
at it half a timer period ago, on average, works. Which would be very
intriguing. We'd probably want nice graphs in this case overlaying
power, request counts, selected EU config, etc.
> A bunch of selftests and igt proving that different sseu setups do
> consume different power (i.e. that we can adjust sseu correctly),
> along with demonstrating good workloads where autotuning produces
> beneficial results is a must.
>
> Also given Tvrtko's stats, this could all be done from userspace with an
> extended CONTEXT_PARAM_SSEU, so why would we not do it that way?
You mean patching and recompiling userspace? I don't think that would
work for them.
Regards,
Tvrtko
More information about the Intel-gfx
mailing list