Re: [PATCH v6 3/3] drm/i915: Predictive governor to control slice/subslice/eu

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux