An error occurred fetching the project authors.
  1. 27 Jul, 2015 2 commits
  2. 14 Jul, 2015 1 commit
  3. 09 Jul, 2015 1 commit
    • Chris Wilson's avatar
      drm/i915: Declare the swizzling unknown for L-shaped configurations · 19ee835c
      Chris Wilson authored
      The old style of memory interleaving swizzled upto the end of the
      first even bank of memory, and then used the remainder as unswizzled on
      the unpaired bank - i.e. swizzling is not constant for all memory. This
      causes problems when we try to migrate memory and so the kernel prevents
      migration at all when we detect L-shaped inconsistent swizzling.
      However, this issue also extends to userspace who try to manually detile
      into memory as the swizzling for an individual page is unknown (it
      depends on its physical address only known to the kernel), userspace
      cannot correctly swizzle objects.
      
      v2: Mark the global swizzling as unknown rather than adjust the value
      reported to userspace.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91105Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      19ee835c
  4. 16 Apr, 2015 1 commit
  5. 24 Feb, 2015 1 commit
  6. 03 Dec, 2014 1 commit
  7. 20 Nov, 2014 1 commit
  8. 11 Nov, 2014 1 commit
    • Chris Wilson's avatar
      drm/i915: Fix obj->map_and_fenceable across tiling changes · e9d784d5
      Chris Wilson authored
      As obj->map_and_fenceable computation has changed to only be set when
      the object is bound inside the global GTT (and is suitable aligned to a
      fence region) we need to accommodate those changes when the tiling is
      adjusted. The easiest solution is to unbind from the global GTT if we
      are currently fenceable, but will not be after the tiling change.
      
      The bug has been exposed by
      
      commit f8fcadba218fe6d23b2e353fea1cf0a4be4c9454
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Fri Oct 31 13:53:52 2014 +0000
      
          drm/i915: Only mark as map-and-fenceable when bound into the GGTT
      
      which tried to fix an oversight from
      
      commit e6a84468
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Mon Aug 11 12:00:12 2014 +0200
      
          drm/i915: Force CPU relocations if not GTT mapped
      
      which changed the handling of obj->map_and_fenceable.
      
      Note that the alignment check is a vestige from our attempts to reduce
      the alignment requirements of tiled but unfenced buffers on
      gen2/3. Also, that was when unbinding from the GTT meant UC writes and
      clflushing, so we went to great pains to avoid such.
      
      That leaves the actual bug of setting map_and_fenceable to true if we're
      not bound to ggtt, which violates the change introduced in the above
      patch. Unbinding in that case really looks like the simplest and safest
      option, we have to do it anyway.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85896
      Testcase: igt/gem_concurrent_blit/gttX*
      Tested-by: huax.lu@intel.com
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: default avatarValtteri Rantala <valtteri.rantala@intel.com>
      [Jani: amend commit message per input from Daniel and bisect result from
      Valtteri]
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      e9d784d5
  9. 07 Nov, 2014 1 commit
  10. 24 Oct, 2014 1 commit
    • Jesse Barnes's avatar
      drm/i915: preserve swizzle settings if necessary v4 · d9ceb816
      Jesse Barnes authored
      Some machines (like MBAs) might use a tiled framebuffer but not enable
      display swizzling at boot time.  We want to preserve that configuration
      if possible to prevent a boot time mode set.  On IVB+ it shouldn't
      affect performance anyway since the memory controller does internal
      swizzling anyway.
      
      For most other configs we'll be able to enable swizzling at boot time,
      since the initial framebuffer won't be tiled, thus we won't see any
      corruption when we enable it.
      
      v2: preserve swizzling if BIOS had it set (Daniel)
      v3: preserve swizzling only if we inherited a tiled framebuffer (Daniel)
          check display swizzle setting in detect_bit_6_swizzle (Daniel)
          use gen6 as cutoff point (Daniel)
      v4: fixup swizzle preserve again, had wrong init order (Daniel)
      Reported-by: default avatarKristian Høgsberg <hoegsberg@gmail.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d9ceb816
  11. 03 Sep, 2014 1 commit
    • Damien Lespiau's avatar
      drm/i915/bdw: Let the memory controller do all the swizzling · be292e15
      Damien Lespiau authored
      Previously, it was possible for the GPU memory accesses to be swizzled
      to try to optimize the fetches for tiled buffers. This swizzling was on
      top of what the memory controller in the uncore already does.
      
      With broadwell, we drop that GPU side swizzling, and the corresponding
      initialization in 3 units (GAM, GT, DE). All those bits are reserved, as
      specs put it:
      
        Before Gen8, there was a historical configuration control field to
        swizzle address bit[6] for in X/Y tiling modes. This was set in three
        different places: TILECTL[1:0], ARB_MODE[5:4], and
        DISP_ARB_CTL[14:13]"
      
        For Gen8 the swizzle fields are all reserved, and the CPU's memory
        controller performs all address swizzling modifications.
      
      This also means that user space doesn't have to manually swizzle when
      accessing tiled buffers from the CPU, and so we always return
      I915_BIT_6_SWIZZLE_NONE from i915_gem_detect_bit_6_swizzle(), which
      short-circuits the initialization of the registers mentionned above in
      i915_gem_init_swizzling().
      
      v2: Refine the explanation a bit more (Daniel)
      v3: Make it BDW+ specific (Steve)
      
      Cc: Steve Aarnio <steve.j.aarnio@linux.intel.com>
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      [danvet: Keep the actual code to set the tiling bits for now, in case
      some bios escaped to the wild that uses this - we'd need it for
      fastboot.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      be292e15
  12. 11 Aug, 2014 1 commit
  13. 31 Mar, 2014 1 commit
  14. 18 Dec, 2013 1 commit
  15. 16 Oct, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: prevent tiling changes on framebuffer backing storage · 80075d49
      Daniel Vetter authored
      Assuming that all framebuffer related metadata is invariant simplifies
      our userspace input data checking. And current userspace always first
      updates the tiling of an object before creating a framebuffer with it.
      
      This allows us to upconvert a check in pin_and_fence to a WARN.
      
      In the future it should also be helpful to know which buffer objects
      are potential scanout targets for e.g. frontbuffer rendering tracking
      and similar things.
      
      Note that SNA shipped for one prerelease with code which will be
      broken through this patch. But users shouldn't notice since it's
      purely an optimization and will transparently fall back to allocating
      a new fb. i-g-t also had offending code (now fixed), but we don't
      really care about breaking the test-suite.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Grumpily-reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      80075d49
  16. 01 Oct, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: Use kcalloc more · a1e22653
      Daniel Vetter authored
      No buffer overflows here, but better safe than sorry.
      
      v2:
      - Fixup the sizeof conversion, I've missed the pointer deref (Jani).
      - Drop the redundant GFP_ZERO, kcalloc alreads memsets (Jani).
      - Use kmalloc_array for the execbuf fastpath to avoid the memset
        (Chris). I've opted to leave all other conversions as-is since they
        aren't in a fastpath and dealing with cleared memory instead of
        random garbage is just generally nicer.
      
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      [danvet: Drop the contentious kmalloc_array hunk in execbuf.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a1e22653
  17. 08 Aug, 2013 1 commit
    • Ben Widawsky's avatar
      drm/i915: plumb VM into bind/unbind code · 07fe0b12
      Ben Widawsky authored
      As alluded to in several patches, and it will be reiterated later... A
      VMA is an abstraction for a GEM BO bound into an address space.
      Therefore it stands to reason, that the existing bind, and unbind are
      the ones which will be the most impacted. This patch implements this,
      and updates all callers which weren't already updated in the series
      (because it was too messy).
      
      This patch represents the bulk of an earlier, larger patch. I've pulled
      out a bunch of things by the request of Daniel. The history is preserved
      for posterity with the email convention of ">" One big change from the
      original patch aside from a bunch of cropping is I've created an
      i915_vma_unbind() function. That is because we always have the VMA
      anyway, and doing an extra lookup is useful. There is a caveat, we
      retain an i915_gem_object_ggtt_unbind, for the global cases which might
      not talk in VMAs.
      
      > drm/i915: plumb VM into object operations
      >
      > This patch was formerly known as:
      > "drm/i915: Create VMAs (part 3) - plumbing"
      >
      > This patch adds a VM argument, bind/unbind, and the object
      > offset/size/color getters/setters. It preserves the old ggtt helper
      > functions because things still need, and will continue to need them.
      >
      > Some code will still need to be ported over after this.
      >
      > v2: Fix purge to pick an object and unbind all vmas
      > This was doable because of the global bound list change.
      >
      > v3: With the commit to actually pin/unpin pages in place, there is no
      > longer a need to check if unbind succeeded before calling put_pages().
      > Make put_pages only BUG() after checking pin count.
      >
      > v4: Rebased on top of the new hangcheck work by Mika
      > plumbed eb_destroy also
      > Many checkpatch related fixes
      >
      > v5: Very large rebase
      >
      > v6:
      > Change BUG_ON to WARN_ON (Daniel)
      > Rename vm to ggtt in preallocate stolen, since it is always ggtt when
      > dealing with stolen memory. (Daniel)
      > list_for_each will short-circuit already (Daniel)
      > remove superflous space (Daniel)
      > Use per object list of vmas (Daniel)
      > Make obj_bound_any() use obj_bound for each vm (Ben)
      > s/bind_to_gtt/bind_to_vm/ (Ben)
      >
      > Fixed up the inactive shrinker. As Daniel noticed the code could
      > potentially count the same object multiple times. While it's not
      > possible in the current case, since 1 object can only ever be bound into
      > 1 address space thus far - we may as well try to get something more
      > future proof in place now. With a prep patch before this to switch over
      > to using the bound list + inactive check, we're now able to carry that
      > forward for every address space an object is bound into.
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      [danvet: Rebase on top of the loss of "drm/i915: Cleanup more of VMA
      in destroy".]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      07fe0b12
  18. 08 Jul, 2013 1 commit
    • Ben Widawsky's avatar
      drm/i915: Getter/setter for object attributes · f343c5f6
      Ben Widawsky authored
      Soon we want to gut a lot of our existing assumptions how many address
      spaces an object can live in, and in doing so, embed the drm_mm_node in
      the object (and later the VMA).
      
      It's possible in the future we'll want to add more getter/setter
      methods, but for now this is enough to enable the VMAs.
      
      v2: Reworked commit message (Ben)
      Added comments to the main functions (Ben)
      sed -i "s/i915_gem_obj_set_color/i915_gem_obj_ggtt_set_color/" drivers/gpu/drm/i915/*.[ch]
      sed -i "s/i915_gem_obj_bound/i915_gem_obj_ggtt_bound/" drivers/gpu/drm/i915/*.[ch]
      sed -i "s/i915_gem_obj_size/i915_gem_obj_ggtt_size/" drivers/gpu/drm/i915/*.[ch]
      sed -i "s/i915_gem_obj_offset/i915_gem_obj_ggtt_offset/" drivers/gpu/drm/i915/*.[ch]
      (Daniel)
      
      v3: Rebased on new reserve_node patch
      Changed DRM_DEBUG_KMS to actually work (will need fixing later)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f343c5f6
  19. 18 Apr, 2013 2 commits
  20. 27 Mar, 2013 1 commit
  21. 23 Mar, 2013 1 commit
  22. 17 Jan, 2013 3 commits
  23. 07 Dec, 2012 1 commit
  24. 03 Oct, 2012 1 commit
  25. 02 Oct, 2012 2 commits
  26. 20 Sep, 2012 1 commit
    • Chris Wilson's avatar
      drm/i915: Replace the array of pages with a scatterlist · 9da3da66
      Chris Wilson authored
      Rather than have multiple data structures for describing our page layout
      in conjunction with the array of pages, we can migrate all users over to
      a scatterlist.
      
      One major advantage, other than unifying the page tracking structures,
      this offers is that we replace the vmalloc'ed array (which can be up to
      a megabyte in size) with a chain of individual pages which helps reduce
      memory pressure.
      
      The disadvantage is that we then do not have a simple array to iterate,
      or to access randomly. The common case for this is in the relocation
      processing, which will typically fit within a single scatterlist page
      and so be almost the same cost as the simple array. For iterating over
      the array, the extra function call could be optimised away, but in
      reality is an insignificant cost of either binding the pages, or
      performing the pwrite/pread.
      
      v2: Fix drm_clflush_sg() to not invoke wbinvd as well! And fix the
      trivial compile error from rebasing.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9da3da66
  27. 03 May, 2012 2 commits
    • Chris Wilson's avatar
      drm/i915: Only the zap the VMA after updating the tiling parameters · 1869b620
      Chris Wilson authored
      If we fail to unbind and so abort the change in tiling, we will have
      removed the VMA for the object for no reason. The likelihood of unbind
      failing is slim (other than ERESTARTSYS which will cause userspace to
      try again), so the change is mostly for the principle.
      
      Also improve the slightly stale comment.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1869b620
    • Chris Wilson's avatar
      drm/i915: Clarify the semantics of tiling_changed · 5d82e3e6
      Chris Wilson authored
      Rename obj->tiling_changed to obj->fence_dirty so that it is clear that
      it flags when the parameters for an active fence (including the
      no-fence) register are changed.
      
      Also, do not set this flag when the object does not have a fence
      register allocated currently and the gpu does not depend upon the
      unfence. This case works exactly like when a tiled object lost its
      fence and hence does not need additional handling for the tiling
      change in the code.
      
      v2: Use fence_dirty to better express what the flag tracks and add a few
      more details to the comments to serve as a reminder of how the GPU also
      uses the unfenced register slot.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      [danvet: Add some bikeshed to the commit message about the stricter
      use of fence_dirty.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5d82e3e6
  28. 08 Feb, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: swizzling support for snb/ivb · f691e2f4
      Daniel Vetter authored
      We have to do this manually. Somebody had a Great Idea.
      
      I've measured speed-ups just a few percent above the noise level
      (below 5% for the best case), but no slowdows. Chris Wilson measured
      quite a bit more (10-20% above the usual snb variance) on a more
      recent and better tuned version of sna, but also recorded a few
      slow-downs on benchmarks know for uglier amounts of snb-induced
      variance.
      
      v2: Incorporate Ben Widawsky's preliminary review comments and
      elaborate a bit about the performance impact in the changelog.
      
      v3: Add a comment as to why we don't need to check the 3rd memory
      channel.
      
      v4: Fixup whitespace.
      Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f691e2f4
  29. 30 Jan, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: fix swizzle detection for gen3 · c9c4b6f6
      Daniel Vetter authored
      It looks like the desktop variants of i915 and i945 also have the DCC
      register to control dram channel interleave and cpu side bit6
      swizzling.
      
      Unfortunately internal Cspec/ConfigDB documentation for these ancient chips
      have already been dropped and there seem to be no archives. Also
      somebody thought the swizzling behaviour is surely a worthy secret to
      keep and redacted any mention of these fields from the published Intel
      datasheets.
      
      I suspect the hw engineers were really proud of the page coloring
      they've achieved in their first dual channel dram controller with
      bit17 - after all Bspec explains in great length the optimal layout of
      page frame numbers modulo 4 for the color and depth buffers, too.
      Later on when they've started to work on VT-d they shamefully
      discoverd their stupidity and tried to cover the tracks ...
      
      Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch> (i915g)
      Tested-by: Pavel Ondračka <pavel.ondracka@email.cz> (i945g)
      Tested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42625Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c9c4b6f6
  30. 20 Oct, 2011 2 commits
  31. 18 Jul, 2011 1 commit
  32. 14 May, 2011 1 commit
  33. 07 Mar, 2011 1 commit