1. 22 Aug, 2013 6 commits
  2. 10 Aug, 2013 4 commits
    • Chris Wilson's avatar
      drm/i915: Allow the GPU to cache stolen memory · d46f1c3f
      Chris Wilson authored
      As a corollary to reviewing the interaction between LLC and our cache
      domains, the GPU PTE bits are independent of the CPU PAT bits. As such
      we can set the cache level on stolen memory based on how we wish the GPU
      to cache accesses to it. So we are free to set the same default cache
      levels as for normal bo, i.e. enable LLC cacheing by default where
      appropriate.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d46f1c3f
    • Chris Wilson's avatar
      drm/i915: Update rules for writing through the LLC with the cpu · 2c22569b
      Chris Wilson authored
      As mentioned in the previous commit, reads and writes from both the CPU
      and GPU go through the LLC. This gives us coherency between the CPU and
      GPU irrespective of the attribute settings either device sets. We can
      use to avoid having to clflush even uncached memory.
      
      Except for the scanout.
      
      The scanout resides within another functional block that does not use
      the LLC but reads directly from main memory. So in order to maintain
      coherency with the scanout, writes to uncached memory must be flushed.
      In order to optimize writes elsewhere, we start tracking whether an
      framebuffer is attached to an object.
      
      v2: Use pin_display tracking rather than fb_count (to ensure we flush
      cursors as well etc) and only force the clflush along explicit writes to
      the scanout paths (i.e. pin_to_display_plane and pwrite into scanout).
      
      v3: Force the flush after hitting the slowpath in pwrite, as after
      dropping the lock the object's cache domain may be invalidated. (Ville)
      
      Based on a patch by Ville Syrjälä.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2c22569b
    • Chris Wilson's avatar
      drm/i915: Track when an object is pinned for use by the display engine · cc98b413
      Chris Wilson authored
      The display engine has unique coherency rules such that it requires
      special handling to ensure that all writes to cursors, scanouts and
      sprites are clflushed. This patch introduces the infrastructure to
      simply track when an object is being accessed by the display engine.
      
      v2: Explain the is_pin_display() magic as the sources for obj->pin_count
      and their individual rules is not obvious. (Ville)
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      cc98b413
    • Chris Wilson's avatar
      drm/i915: Update rules for reading cache lines through the LLC · c76ce038
      Chris Wilson authored
      The LLC is a fun device. The cache is a distinct functional block within
      the SA that arbitrates access from both the CPU and GPU cores. As such
      all writes to memory land first in the LLC before further action is
      taken. For example, an uncached write from either the CPU or GPU will
      then proceed to memory and evict the cacheline from the LLC. This means that
      a read from the LLC always returns the correct information even if the PTE
      bit in the GPU differs from the PAT bit in the CPU. For the older
      snooping architecture on non-LLC, the fundamental principle still holds
      except that some coordination is required between the CPU and GPU to
      explicitly perform the snooping (which is handled by our request
      tracking).
      
      The upshot of this is that we know that we can issue a read from either
      LLC devices or snoopable memory and trust the contents of the cache -
      i.e. we can forgo a clflush before a read in these circumstances.
      Writing to memory from the CPU is a little more tricky as we have to
      consider that the scanout does not read from the CPU cache at all, but
      from main memory. So we have to currently treat all requests to write to
      uncached memory as having to be flushed to main memory for coherency
      with all consumers.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c76ce038
  3. 09 Aug, 2013 11 commits
  4. 08 Aug, 2013 19 commits