1. 04 Oct, 2013 1 commit
  2. 03 Oct, 2013 10 commits
    • Rodrigo Vivi's avatar
      drm/i915: Simplify PSR debugfs · a031d709
      Rodrigo Vivi authored
      for igt test case.
      
      v2: remove trailing spaces and fix conflicts
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@gmail.com>
      [danvet:
      - make it comipile
      - s/IS_HASWELL/HAS_PSR/]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a031d709
    • Chris Wilson's avatar
      drm/i915: Tweak RPS thresholds to more aggressively downclock · dd75fdc8
      Chris Wilson authored
      After applying wait-boost we often find ourselves stuck at higher clocks
      than required. The current threshold value requires the GPU to be
      continuously and completely idle for 313ms before it is dropped by one
      bin. Conversely, we require the GPU to be busy for an average of 90% over
      a 84ms period before we upclock. So the current thresholds almost never
      downclock the GPU, and respond very slowly to sudden demands for more
      power. It is easy to observe that we currently lock into the wrong bin
      and both underperform in benchmarks and consume more power than optimal
      (just by repeating the task and measuring the different results).
      
      An alternative approach, as discussed in the bspec, is to use a
      continuous threshold for upclocking, and an average value for downclocking.
      This is good for quickly detecting and reacting to state changes within a
      frame, however it fails with the common throttling method of waiting
      upon the outstanding frame - at least it is difficult to choose a
      threshold that works well at 15,000fps and at 60fps. So continue to use
      average busy/idle loads to determine frequency change.
      
      v2: Use 3 power zones to keep frequencies low in steady-state mostly
      idle (e.g. scrolling, interactive 2D drawing), and frequencies high
      for demanding games. In between those end-states, we use a
      fast-reclocking algorithm to converge more quickly on the desired bin.
      
      v3: Bug fixes - make sure we reset adj after switching power zones.
      
      v4: Tune - drop the continuous busy thresholds as it prevents us from
      choosing the right frequency for glxgears style swap benchmarks. Instead
      the goal is to be able to find the right clocks irrespective of the
      wait-boost.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Kenneth Graunke <kenneth@whitecape.org>
      Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
      Cc: Owen Taylor <otaylor@redhat.com>
      Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
      Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      dd75fdc8
    • Chris Wilson's avatar
      drm/i915: Boost RPS frequency for CPU stalls · b29c19b6
      Chris Wilson authored
      If we encounter a situation where the CPU blocks waiting for results
      from the GPU, give the GPU a kick to boost its the frequency.
      
      This should work to reduce user interface stalls and to quickly promote
      mesa to high frequencies - but the cost is that our requested frequency
      stalls high (as we do not idle for long enough before rc6 to start
      reducing frequencies, nor are we aggressive at down clocking an
      underused GPU). However, this should be mitigated by rc6 itself powering
      off the GPU when idle, and that energy use is dependent upon the workload
      of the GPU in addition to its frequency (e.g. the math or sampler
      functions only consume power when used). Still, this is likely to
      adversely affect light workloads.
      
      In particular, this nearly eliminates the highly noticeable wake-up lag
      in animations from idle. For example, expose or workspace transitions.
      (However, given the situation where we fail to downclock, our requested
      frequency is almost always the maximum, except for Baytrail where we
      manually downclock upon idling. This often masks the latency of
      upclocking after being idle, so animations are typically smooth - at the
      cost of increased power consumption.)
      
      Stéphane raised the concern that this will punish good applications and
      reward bad applications - but due to the nature of how mesa performs its
      client throttling, I believe all mesa applications will be roughly
      equally affected. To address this concern, and to prevent applications
      like compositors from permanently boosting the RPS state, we ratelimit the
      frequency of the wait-boosts each client recieves.
      
      Unfortunately, this techinique is ineffective with Ironlake - which also
      has dynamic render power states and suffers just as dramatically. For
      Ironlake, the thermal/power headroom is shared with the CPU through
      Intelligent Power Sharing and the intel-ips module. This leaves us with
      no GPU boost frequencies available when coming out of idle, and due to
      hardware limitations we cannot change the arbitration between the CPU and
      GPU quickly enough to be effective.
      
      v2: Limit each client to receiving a single boost for each active period.
          Tested by QA to only marginally increase power, and to demonstrably
          increase throughput in games. No latency measurements yet.
      
      v3: Cater for front-buffer rendering with manual throttling.
      
      v4: Tidy up.
      
      v5: Sadly the compositor needs frequent boosts as it may never idle, but
      due to its picking mechanism (using ReadPixels) may require frequent
      waits. Those waits, along with the waits for the vrefresh swap, conspire
      to keep the GPU at low frequencies despite the interactive latency. To
      overcome this we ditch the one-boost-per-active-period and just ratelimit
      the number of wait-boosts each client can receive.
      Reported-and-tested-by: default avatarPaul Neumann <paul104x@yahoo.de>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Kenneth Graunke <kenneth@whitecape.org>
      Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
      Cc: Owen Taylor <otaylor@redhat.com>
      Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
      Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      [danvet: No extern for function prototypes in headers.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b29c19b6
    • Chris Wilson's avatar
      drm/i915: Fix __wait_seqno to use true infinite timeouts · 094f9a54
      Chris Wilson authored
      When we switched to always using a timeout in conjunction with
      wait_seqno, we lost the ability to detect missed interrupts. Since, we
      have had issues with interrupts on a number of generations, and they are
      required to be delivered in a timely fashion for a smooth UX, it is
      important that we do log errors found in the wild and prevent the
      display stalling for upwards of 1s every time the seqno interrupt is
      missed.
      
      Rather than continue to fix up the timeouts to work around the interface
      impedence in wait_event_*(), open code the combination of
      wait_event[_interruptible][_timeout], and use the exposed timer to
      poll for seqno should we detect a lost interrupt.
      
      v2: In order to satisfy the debug requirement of logging missed
      interrupts with the real world requirments of making machines work even
      if interrupts are hosed, we revert to polling after detecting a missed
      interrupt.
      
      v3: Throw in a debugfs interface to simulate broken hw not reporting
      interrupts.
      
      v4: s/EGAIN/EAGAIN/ (Imre)
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      [danvet: Don't use the struct typedef in new code.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      094f9a54
    • Chris Wilson's avatar
      drm/i915: Add some missing steps to i915_driver_load error path · cbb47d17
      Chris Wilson authored
      We missed adding a few cleanup steps for recent additions.
      
      Reviewer:  Ben Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@gmail.com>
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      cbb47d17
    • Ben Widawsky's avatar
      drm/i915: Clean up the ring scaling calculations · f6aca45c
      Ben Widawsky authored
      This patch attempts to clean up the ring/IA scaling programming in the
      following ways.
      1. Fix the comment about the DDR frequency. The math is 266MHz, not
      133MHz. Formula was right, docs are wrong.
      
      2. Mask the DCLK register since I don't know how it is defined on future
      platforms.
      
      3. use mult_frac instead of magic math.
      
      This helps for future platform enabling.
      
      v2: Actually use the right patch. The v1 was a mix of things, none of
      which was right. Note that due to rounding, we actually get different
      values (slightly higher) for the effective ring frequency.
      
      v3: Use 1.25 instead of 1.33 as the original code did. (Jesse)
      
      CC: Jesse Barnes <jbarnes@virtuousgeek.org>
      CC: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f6aca45c
    • Ville Syrjälä's avatar
      drm/i915: Don't populate pipe_src_{w,h} multiple times · e41a56be
      Ville Syrjälä authored
      If we ever end up doing the retry loop due to bandwidth constraints, we
      would rewrite pipe_src_{w,n} based on adjusted_mode timings. But by that
      time the encoder may have already replaced the adjusted_mode with a
      fixed panel mode, which would then corrupt pipe_src_{w,h}.
      
      v2: Use requested_mode and slap on a big comment from Daniel
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e41a56be
    • Paulo Zanoni's avatar
      drm/i915: implement the Haswell mode set sequence workaround · e4916946
      Paulo Zanoni authored
      This workaround is described in the mode set sequence documentation.
      When enabling planes for the second pipe, we need to wait for 2
      vblanks on the first pipe. This should solve "a flash of screen
      corruption if planes are enabled on second/third pipe during the time
      that big FIFO mode is exiting". Watermarks are fun :)
      
      v2: Save indentation levels
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e4916946
    • Ville Syrjälä's avatar
      drm/i915: Disable/enable planes as the first/last thing during modeset on HSW · dda9a66a
      Ville Syrjälä authored
      Refactor the plane enabling/disabling into helper functions and move
      the calls to happen as the first thing during .crtc_disable, and the
      last thing during .crtc_enable.
      
      Those are the two clear points where we are sure that the pipe is
      actually running regardless of the encoder type or hardware
      generation.
      
      v2: Made by Paulo:
        Remove the code touching everything but the Haswell functions. We
        need this change on Haswell right now since it fixes a FIFO underrun
        that we get on pipe A while we enable pipe B (see the workaround
        notes on the Haswell mode set sequence documentation). We can bring
        back the code to gens 2-7 later, once they're tested.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      dda9a66a
    • Jesse Barnes's avatar
      i915/vlv: untangle integrated clock source handling v4 · f6071166
      Jesse Barnes authored
      The global integrated clock source bit resides in DPLL B on VLV, but we
      were treating it as a per-pipe resource.  It needs to be set whenever
      any PLL is active, so pull setting the bit out of vlv_update_pll and
      into vlv_enable_pll.  Also add a vlv_disable_pll to prevent disabling it
      when pipe B shuts down.
      
      I'm guessing on the references here, I expect this to bite any config
      where multiple displays are active or displays are moved from pipe to
      pipe.
      
      v2: re-add bits in vlv_update_pll to keep from confusing the state checker
      v3: use enum pipe checks (Daniel)
          set CRI clock source early (Ville)
          consistently set CRI clock source everywhere (Ville)
      v4: drop unnecessary setting of bit in vlv enable pll (Ville)
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=67245
      References: https://bugs.freedesktop.org/show_bug.cgi?id=69693Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      [danvet: s/1/PIPE_B/]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f6071166
  3. 01 Oct, 2013 29 commits