[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