1. 01 9月, 2017 1 次提交
  2. 31 8月, 2017 1 次提交
  3. 23 8月, 2017 1 次提交
    • C
      drm/i915: Boost GPU clocks if we miss the pageflip's vblank · 74d290f8
      Chris Wilson 提交于
      If we miss the current vblank because the gpu was busy, that may cause a
      jitter as the frame rate temporarily drops. We try to limit the impact
      of this by then boosting the GPU clock to deliver the frame as quickly
      as possible. Originally done in commit 6ad790c0 ("drm/i915: Boost GPU
      frequency if we detect outstanding pageflips") but was never forward
      ported to atomic and finally dropped in commit fd3a4024 ("drm/i915:
      Rip out legacy page_flip completion/irq handling").
      
      One of the most typical use-cases for this is a mostly idle desktop.
      Rendering one frame of the desktop's frontbuffer can easily be
      accomplished by the GPU running at low frequency, but often exceeds
      the time budget of the desktop compositor. The result is that animations
      such as opening the menu, doing a fullscreen switch, or even just trying
      to move a window around are slow and jerky. We need to respond within a
      frame to give the best impression of a smooth UX, as a compromise we
      instead respond if that first frame misses its goal. The result should
      be a near-imperceivable initial delay and a smooth animation even
      starting from idle. The cost, as ever, is that we spend more power than
      is strictly necessary as we overestimate the required GPU frequency and
      then try to ramp down.
      
      This of course is reactionary, too little, too late; nevertheless it is
      surprisingly effective.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102199Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170817123706.6777-1-chris@chris-wilson.co.ukTested-by: NLyude Paul <lyude@redhat.com>
      Reviewed-by: NRadoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
      74d290f8
  4. 19 8月, 2017 2 次提交
  5. 16 8月, 2017 1 次提交
  6. 11 8月, 2017 5 次提交
  7. 04 8月, 2017 1 次提交
  8. 28 7月, 2017 2 次提交
  9. 19 7月, 2017 1 次提交
  10. 13 7月, 2017 4 次提交
  11. 08 7月, 2017 1 次提交
  12. 28 6月, 2017 1 次提交
    • C
      drm/i915: Avoid keeping waitboost active for signaling threads · 7b92c1bd
      Chris Wilson 提交于
      Once a client has requested a waitboost, we keep that waitboost active
      until all clients are no longer waiting. This is because we don't
      distinguish which waiter deserves the boost. However, with the advent of
      fence signaling, the signaler threads appear as waiters to the RPS
      interrupt handler. So instead of using a single boolean to track when to
      keep the waitboost active, use a counter of all outstanding waitboosted
      requests.
      
      At this point, I have removed all vestiges of the rate limiting on
      clients. Whilst this means that compositors should remain more fluid,
      it also means that boosts are more prevalent. See commit b29c19b6
      ("drm/i915: Boost RPS frequency for CPU stalls") for a longer discussion
      on the pros and cons of both approaches.
      
      A drawback of this implementation is that it requires constant request
      submission to keep the waitboost trimmed (as it is now cancelled when the
      request is completed). This will be fine for a busy system, but near
      idle the boosts may be kept for longer than desired (effectively tens of
      vblanks worstcase) and there is a reliance on rc6 instead.
      
      v2: Remove defunct rps.client_lock
      Reported-by: NMichał Winiarski <michal.winiarski@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170628123548.9236-1-chris@chris-wilson.co.uk
      7b92c1bd
  13. 16 6月, 2017 1 次提交
  14. 13 6月, 2017 1 次提交
  15. 09 6月, 2017 1 次提交
  16. 07 6月, 2017 2 次提交
  17. 01 6月, 2017 4 次提交
  18. 18 5月, 2017 9 次提交
  19. 10 5月, 2017 1 次提交