[Bug 107111] "Avoid waitboosting" (e9af4ea2b9e7) now prevents GPU boosting

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107111

Chris Wilson <chris at chris-wilson.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #9 from Chris Wilson <chris at chris-wilson.co.uk> ---
commit 60548c554be2830d29d2533dad0ac8133347ee51 (HEAD -> drm-intel-next-queued,
drm-intel/for-linux-next, drm-intel/drm-intel-next-queued)
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Tue Jul 31 14:26:29 2018 +0100

    drm/i915: Interactive RPS mode

    RPS provides a feedback loop where we use the load during the previous
    evaluation interval to decide whether to up or down clock the GPU
    frequency. Our responsiveness is split into 3 regimes, a high and low
    plateau with the intent to keep the gpu clocked high to cover occasional
    stalls under high load, and low despite occasional glitches under steady
    low load, and inbetween. However, we run into situations like kodi where
    we want to stay at low power (video decoding is done efficiently
    inside the fixed function HW and doesn't need high clocks even for high
    bitrate streams), but just occasionally the pipeline is more complex
    than a video decode and we need a smidgen of extra GPU power to present
    on time. In the high power regime, we sample at sub frame intervals with
    a bias to upclocking, and conversely at low power we sample over a few
    frames worth to provide what we consider to be the right levels of
    responsiveness respectively. At low power, we more or less expect to be
    kicked out to high power at the start of a busy sequence by waitboosting.

    Prior to commit e9af4ea2b9e7 ("drm/i915: Avoid waitboosting on the active
    request") whenever we missed the frame or stalled, we would immediate go
    full throttle and upclock the GPU to max. But in commit e9af4ea2b9e7, we
    relaxed the waitboosting to only apply if the pipeline was deep to avoid
    over-committing resources for a near miss. Sadly though, a near miss is
    still a miss, and perceptible as jitter in the frame delivery.

    To try and prevent the near miss before having to resort to boosting
    after the fact, we use the pageflip queue as an indication that we are
    in an "interactive" regime and so should sample the load more frequently
    to provide power before the frame misses it vblank. This will make us
    more favorable to providing a small power increase (one or two bins) as
    required rather than going all the way to maximum and then having to
    work back down again. (We still keep the waitboosting mechanism around
    just in case a dramatic change in system load requires urgent uplocking,
    faster than we can provide in a few evaluation intervals.)

    v2: Reduce rps_set_interactive to a boolean parameter to avoid the
    confusion of what if they wanted a new power mode after pinning to a
    different mode (which to choose?)
    v3: Only reprogram RPS while the GT is awake, it will be set when we
    wake the GT, and while off warns about being used outside of rpm.
    v4: Fix deferred application of interactive mode
    v5: s/state/interactive/
    v6: Group the mutex with its principle in a substruct

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107111
    Fixes: e9af4ea2b9e7 ("drm/i915: Avoid waitboosting on the active request")
    Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
    Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
    Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
    Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg at intel.com>
    Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
    Reviewed-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
    Link:
https://patchwork.freedesktop.org/patch/msgid/20180731132629.3381-1-chris@chris-wilson.co.uk

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180731/f69b4b08/attachment.html>