1. 05 Aug, 2015 2 commits
    • Paulo Zanoni's avatar
      drm/i915: don't call intel_fbc_update() at intel_unpin_work_fn() · 698e84ed
      Paulo Zanoni authored
      Because intel_unpin_work_fn() already calls
      intel_frontbuffer_flip_complete() which will call intel_fbc_flush()
      which will call intel_fbc_update() when needed.
      
      We couldn't fix this previously due to the fact that FBC was not
      properly behaving as intended on frontbuffer flushes, but now that
      this is fixed, we can remove the additional call.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      698e84ed
    • Paulo Zanoni's avatar
      drm/i915: fix FBC frontbuffer tracking flushing code · 6f4551fe
      Paulo Zanoni authored
      Due to the way busy_bits was handled, we were not doing any flushes if
      we didn't previously get an invalidate. Since it's possible to get
      flushes without an invalidate first, remove the busy_bits early
      return.
      
      So now that we don't have the busy_bits guard anymore we'll need the
      origin check for the GTT tracking (we were not doing anything on GTT
      flushes due to the GTT check at invalidate()).
      
      As a last detail, since we can get multiple consecutive flushes,
      disable FBC before updating it, otherwise intel_fbc_update() will just
      keep FBC enabled instead of restarting it.
      
      Notice that this does not fix any of the current IGT tests due to the
      fact that we still have a few intel_fbc() calls at points where we
      also have the frontbuffer tracking calls: we didn't fully convert to
      frontbuffer tracking yet. Once we remove those calls and start relying
      only on the frontbuffer tracking infrastructure we'll need this patch.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6f4551fe
  2. 31 Jul, 2015 1 commit
  3. 29 Jul, 2015 4 commits
  4. 28 Jul, 2015 2 commits
    • Chris Wilson's avatar
      drm/i915: Keep the mm.bound_list in rough LRU order · 6c246959
      Chris Wilson authored
      When we shrink our working sets, we want to avoid stealing pages from
      objects that likely to be reused in the near future. We first look at
      inactive objects before processing active objects - but what about a
      recently active object that is about to be used again. That object's
      position in the bound_list is ordered by the time of binding, not the
      time of last use, so the most recently used inactive object could well
      be at the head of the shrink list. To compensate, give the object a bump
      to MRU when it becomes inactive (thus transitioning to the end of the
      first pass in shrink lists). Conversely, bumping on inactive makes
      bumping on active useless, since when we do have to reap from the active
      working set, everything is going to become inactive very quickly and the
      order pretty much random - just hope for the best at that point, as once
      we start stalling on active objects, we can hope that the rebinding
      neatly orders vital objects.
      Suggested-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      [danvet: Resolve merge conflict.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6c246959
    • Daniel Vetter's avatar
      drm/i915: Fake AGP is dead · 3b9a02e8
      Daniel Vetter authored
      Remove the leftovers, yay!
      
      AGP for i915 kms died long ago with
      
      commit 3bb6ce66
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Wed Nov 13 22:14:16 2013 +0100
      
          drm/i915: Kill legeacy AGP for gen3 kms
      
      and with ums now gone to there's really no users any more.
      
      Note that device_is_agp is only called when DRIVER_USE_AGP is set and
      since we've unconditionally cleared that since a while there are
      really no users left for i915_driver_device_is_agp.
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      3b9a02e8
  5. 27 Jul, 2015 6 commits
  6. 22 Jul, 2015 3 commits
  7. 21 Jul, 2015 7 commits
  8. 20 Jul, 2015 1 commit
  9. 17 Jul, 2015 4 commits
  10. 15 Jul, 2015 10 commits