Lionel Landwerlin <lionel.g.landwerlin@xxxxxxxxx> writes: > On 15/03/2020 02:12, Francisco Jerez wrote: >> srinivasan.s@xxxxxxxxx writes: >> >>> From: Srinivasan S <srinivasan.s@xxxxxxxxx> >>> >>> drm/i915: Context aware user agnostic EU/Slice/Sub-slice control within kernel >>> >>> This patch sets improves GPU power consumption on Linux kernel based OS such as >>> Chromium OS, Ubuntu, etc. Following are the power savings. >>> >>> Power savings on GLK-GT1 Bobba platform running on Chrome OS. >>> -----------------------------------------------| >>> App /KPI | % Power Benefit (mW) | >>> ------------------------|----------------------| >>> Hangout Call- 20 minute | 1.8% | >>> Youtube 4K VPB | 14.13% | >>> WebGL Aquarium | 13.76% | >>> Unity3D | 6.78% | >>> | | >>> ------------------------|----------------------| >>> Chrome PLT | BatteryLife Improves | >>> | by ~45 minute | >>> -----------------------------------------------| >>> >>> Power savings on KBL-GT3 running on Android and Ubuntu (Linux). >>> -----------------------------------------------| >>> App /KPI | % Power Benefit (mW) | >>> |----------------------| >>> | Android | Ubuntu | >>> ------------------------|----------|-----------| >>> 3D Mark (Ice storm) | 2.30% | N.A. | >>> TRex On screen | 2.49% | 2.97% | >>> Manhattan On screen | 3.11% | 4.90% | >>> Carchase On Screen | N.A. | 5.06% | >>> AnTuTu 6.1.4 | 3.42% | N.A. | >>> SynMark2 | N.A. | 1.7% | >>> -----------------------------------------------| >>> >> Did you get any performance (e.g. FPS) measurements from those >> test-cases? There is quite some potential for this feature to constrain >> the GPU throughput inadvertently, which could lead to an apparent >> reduction in power usage not accompanied by an improvement in energy >> efficiency -- In fact AFAIUI there is some potential for this feature to >> *decrease* the energy efficiency of the system if the GPU would have >> been able to keep all EUs busy at a lower frequency, but the parallelism >> constraint forces it to run at a higher frequency above RPe in order to >> achieve the same throughput, because due to the convexity of the power >> curve of the EU we have: >> >> P(k * f) > k * P(f) >> >> Where 'k' is the ratio between the EU parallelism without and with SSEU >> control, and f > RPe is the original GPU frequency without SSEU control. >> >> In scenarios like that we *might* seem to be using less power with SSEU >> control if the workload is running longer, but it would end up using >> more energy overall by the time it completes, so it would be good to >> have some performance-per-watt numbers to make sure that's not >> happening. >> >>> We have also observed GPU core residencies improves by 1.035%. >>> >>> Technical Insights of the patch: >>> Current GPU configuration code for i915 does not allow us to change >>> EU/Slice/Sub-slice configuration dynamically. Its done only once while context >>> is created. >>> >>> While particular graphics application is running, if we examine the command >>> requests from user space, we observe that command density is not consistent. >>> It means there is scope to change the graphics configuration dynamically even >>> while context is running actively. This patch series proposes the solution to >>> find the active pending load for all active context at given time and based on >>> that, dynamically perform graphics configuration for each context. >>> >>> We use a hr (high resolution) timer with i915 driver in kernel to get a >>> callback every few milliseconds (this timer value can be configured through >>> debugfs, default is '0' indicating timer is in disabled state i.e. original >>> system without any intervention).In the timer callback, we examine pending >>> commands for a context in the queue, essentially, we intercept them before >>> they are executed by GPU and we update context with required number of EUs. >>> >> Given that the EU configuration update is synchronous with command >> submission, do you really need a timer? It sounds like it would be less >> CPU overhead to adjust the EU count on demand whenever the counter >> reaches or drops below the threshold instead of polling some CPU-side >> data structure. >> >>> Two questions, how did we arrive at right timer value? and what's the right >>> number of EUs? For the prior one, empirical data to achieve best performance >>> in least power was considered. For the later one, we roughly categorized number >>> of EUs logically based on platform. Now we compare number of pending commands >>> with a particular threshold and then set number of EUs accordingly with update >>> context. That threshold is also based on experiments & findings. If GPU is able >>> to catch up with CPU, typically there are no pending commands, the EU config >>> would remain unchanged there. In case there are more pending commands we >>> reprogram context with higher number of EUs. Please note, here we are changing >>> EUs even while context is running by examining pending commands every 'x' >>> milliseconds. >>> >> I have doubts that the number of requests pending execution is a >> particularly reliable indicator of the optimal number of EUs the >> workload needs enabled, for starters because the execlists submission >> code seems to be able to merge multiple requests into the same port, so >> there might seem to be zero pending commands even if the GPU has a >> backlog of several seconds or minutes worth of work. >> >> But even if you were using an accurate measure of the GPU load, would >> that really be a good indicator of whether the GPU would run more >> efficiently with more or less EUs enabled? I can think of many >> scenarios where a short-lived GPU request would consume less energy and >> complete faster while running with all EUs enabled (e.g. if it actually >> has enough parallelism to take advantage of all EUs in the system). >> Conversely I can think of some scenarios where a long-running GPU >> request would benefit from SSEU control (e.g. a poorly parallelizable >> but heavy 3D geometry pipeline or GPGPU workload). The former seems >> more worrying than the latter since it could lead to performance or >> energy efficiency regressions. >> >> IOW it seems to me that the optimal number of EUs enabled is more of a >> function of the internal parallelism constraints of each request rather >> than of the overall GPU load. You should be able to get some >> understanding of that by e.g. calculating the number of threads loaded >> on the average based on the EU SPM counters, but unfortunately the ones >> you'd need are only available on TGL+ IIRC. On earlier platforms you >> should be able to achieve the same thing by sampling some FLEXEU >> counters, but you'd likely have to mess with the mux configuration which >> would interfere with OA sampling -- However it sounds like this feature >> may have to be disabled anytime OA is active anyway so that may not be a >> problem after all? > > > FLEXEU has to be configured on all contexts but does not need the mux > configuration. > They have a sort of mux controlled through the EU_PERF_CNT_CTL* registers that have to be set up correctly for each counter to count the right event, which would certainly interfere with userspace using OA to gather EU metrics. > I think this feature would have to be shut off everytime you end using > OA from userspace though. > Yeah, that's probably necessary one way or another. > > -Lionel > > >> >> Regards, >> Francisco. >> >>> Srinivasan S (3): >>> drm/i915: Get active pending request for given context >>> drm/i915: set optimum eu/slice/sub-slice configuration based on load >>> type >>> drm/i915: Predictive governor to control slice/subslice/eu >>> >>> drivers/gpu/drm/i915/Makefile | 1 + >>> drivers/gpu/drm/i915/gem/i915_gem_context.c | 20 +++++ >>> drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 + >>> drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 38 ++++++++ >>> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 1 + >>> drivers/gpu/drm/i915/gt/intel_deu.c | 104 ++++++++++++++++++++++ >>> drivers/gpu/drm/i915/gt/intel_deu.h | 31 +++++++ >>> drivers/gpu/drm/i915/gt/intel_lrc.c | 44 ++++++++- >>> drivers/gpu/drm/i915/i915_drv.h | 6 ++ >>> drivers/gpu/drm/i915/i915_gem.c | 4 + >>> drivers/gpu/drm/i915/i915_params.c | 4 + >>> drivers/gpu/drm/i915/i915_params.h | 1 + >>> drivers/gpu/drm/i915/intel_device_info.c | 74 ++++++++++++++- >>> 13 files changed, 325 insertions(+), 5 deletions(-) >>> create mode 100644 drivers/gpu/drm/i915/gt/intel_deu.c >>> create mode 100644 drivers/gpu/drm/i915/gt/intel_deu.h >>> >>> -- >>> 2.7.4 >>> >>> _______________________________________________ >>> Intel-gfx mailing list >>> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx >>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx >>> >>> _______________________________________________ >>> Intel-gfx mailing list >>> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx >>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
