1. 09 2月, 2012 1 次提交
    • D
      drm/i915: swizzling support for snb/ivb · f691e2f4
      Daniel Vetter 提交于
      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: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NEric Anholt <eric@anholt.net>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f691e2f4
  2. 31 1月, 2012 1 次提交
    • D
      drm/i915: fix swizzle detection for gen3 · c9c4b6f6
      Daniel Vetter 提交于
      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: NChris Wilson <chris@chris-wilson.co.uk>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42625Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c9c4b6f6
  3. 21 10月, 2011 2 次提交
  4. 19 7月, 2011 1 次提交
  5. 14 5月, 2011 1 次提交
  6. 07 3月, 2011 1 次提交
  7. 06 3月, 2011 1 次提交
  8. 24 2月, 2011 1 次提交
  9. 22 2月, 2011 1 次提交
    • C
      drm/i915: Protect against drm_gem_object not being the first member · c8725226
      Chris Wilson 提交于
      Dave Airlie spotted that we had a potential bug should we ever rearrange
      the drm_i915_gem_object so not the base drm_gem_object was not its first
      member. He noticed that we often convert the return of
      drm_gem_object_lookup() immediately into drm_i915_gem_object and then
      check the result for nullity. This is only valid when the base object is
      the first member and so the superobject has the same address. Play safe
      instead and use the compiler to convert back to the original return
      address for sanity testing.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      c8725226
  10. 27 1月, 2011 1 次提交
  11. 02 12月, 2010 1 次提交
    • C
      drm/i915: Pipelined fencing [infrastructure] · d9e86c0e
      Chris Wilson 提交于
      With this change, every batchbuffer can use all available fences (save
      pinned and scanout, of course) without ever stalling the gpu!
      
      In theory. Currently the actual pipelined update of the register is
      disabled due to some stability issues. However, just the deferred update
      is a significant win.
      
      Based on a series of patches by Daniel Vetter.
      
      The premise is that before every access to a buffer through the GTT we
      have to declare whether we need a register or not. If the access is by
      the GPU, a pipelined update to the register is made via the ringbuffer,
      and we track the last seqno of the batches that access it. If by the
      CPU we wait for the last GPU access and update the register (either
      to clear or to set it for the current buffer).
      
      One advantage of being able to pipeline changes is that we can defer the
      actual updating of the fence register until we first need to access the
      object through the GTT, i.e. we can eliminate the stall on set_tiling.
      This is important as the userspace bo cache does not track the tiling
      status of active buffers which generate frequent stalls on gen3 when
      enabling tiling for an already bound buffer.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d9e86c0e
  12. 24 11月, 2010 1 次提交
  13. 15 11月, 2010 1 次提交
  14. 29 10月, 2010 1 次提交
    • C
      drm/i915: Only enforce fence limits inside the GTT. · a00b10c3
      Chris Wilson 提交于
      So long as we adhere to the fence registers rules for alignment and no
      overlaps (including with unfenced accesses to linear memory) and account
      for the tiled access in our size allocation, we do not have to allocate
      the full fenced region for the object. This allows us to fight the bloat
      tiling imposed on pre-i965 chipsets and frees up RAM for real use. [Inside
      the GTT we still suffer the additional alignment constraints, so it doesn't
      magic allow us to render larger scenes without stalls -- we need the
      expanded GTT and fence pipelining to overcome those...]
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      a00b10c3
  15. 22 10月, 2010 1 次提交
  16. 25 9月, 2010 1 次提交
    • C
      drm/i915: Adjust hangcheck EIO semantics · 30dbf0c0
      Chris Wilson 提交于
      Owain Ainsworth reported an issue between the interaction of the
      hangcheck and userspace immediately (and permanently) falling back to
      s/w rasterisation. In order to break the mutex and begin resetting the
      GPU, we must abort the current operation (usually within the wait) and
      climb sufficiently far back up the call chain to drop the mutex. In his
      implementation, Owain has a loop within the ioctl handler to detect the
      hang and then sleep until the error handler has run. I've chosen to
      return to userspace and report an EAGAIN which should trigger the
      userspace ioctl handler to repeat the call (simply because it felt less
      invasive...). Before hitting a wedged GPU, we then wait upon completion
      of the error handler.
      Reported-by: NOwain G. Ainsworth <zerooa@googlemail.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      30dbf0c0
  17. 21 9月, 2010 1 次提交
  18. 15 9月, 2010 1 次提交
  19. 08 9月, 2010 1 次提交
  20. 10 8月, 2010 1 次提交
  21. 02 8月, 2010 1 次提交
  22. 11 5月, 2010 1 次提交
  23. 19 4月, 2010 1 次提交
    • D
      drm/i915: fix tiling limits for i915 class hw v2 · c36a2a6d
      Daniel Vetter 提交于
      Current code is definitely crap: Largest pitch allowed spills into
      the TILING_Y bit of the fence registers ... :(
      
      I've rewritten the limits check under the assumption that 3rd gen hw
      has a 3d pitch limit of 8kb (like 2nd gen). This is supported by an
      otherwise totally misleading XXX comment.
      
      This bug mostly resulted in tiling-corrupted pixmaps because the kernel
      allowed too wide buffers to be tiled. Bug brought to the light by the
      xf86-video-intel 2.11 release because that unconditionally enabled
      tiling for pixmaps, relying on the kernel to check things. Tiling for
      the framebuffer was not affected because the ddx does some additional
      checks there ensure the buffer is within hw-limits.
      
      v2: Instead of computing the value that would be written into the
      hw fence registers and then checking the limits simply check whether
      the stride is above the 8kb limit. To better document the hw, add
      some WARN_ONs in i915_write_fence_reg like I've done for the i830
      case (using the right limits).
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27449Tested-by: NAlexander Lam <lambchop468@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NEric Anholt <eric@anholt.net>
      c36a2a6d
  24. 26 3月, 2010 1 次提交
  25. 19 3月, 2010 1 次提交
  26. 27 2月, 2010 1 次提交
  27. 23 2月, 2010 2 次提交
  28. 17 2月, 2010 1 次提交
  29. 11 2月, 2010 1 次提交
  30. 07 1月, 2010 1 次提交
  31. 08 12月, 2009 1 次提交
  32. 06 11月, 2009 1 次提交
  33. 08 9月, 2009 1 次提交
    • D
      drm/i915: get the bridge device once. · ec2a4c3f
      Dave Airlie 提交于
      The driver gets the bridge device in a number of places, upcoming
      vga arb code paths need the bridge device, however they need it in
      under a lock, and the pci lookup can allocate memory. So clean
      this code up before then and get the bridge once for the driver lifetime.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      ec2a4c3f
  34. 05 9月, 2009 1 次提交
  35. 11 7月, 2009 1 次提交
  36. 19 6月, 2009 2 次提交
  37. 10 6月, 2009 1 次提交