1. 04 Jun, 2009 3 commits
    • Eric Anholt's avatar
      drm/i915: Change GEM throttling to be 20ms like the comment says. · b962442e
      Eric Anholt authored
      keithp didn't like the original 20ms plan because a cooperative client could
      be starved by an uncooperative client.  There may even have been problems
      with cooperative clients versus cooperative clients.  So keithp changed
      throttle to just wait for the second to last seqno emitted by that client.
      It worked well, until we started getting more round-trips to the server
      due to DRI2 -- the server throttles in BlockHandler, and so if you did more
      than one round trip after finishing your frame, you'd end up unintentionally
      syncing to the swap.
      Fix this by keeping track of the client's requests, so the client can wait
      when it has an outstanding request over 20ms old.  This should have
      non-starving behavior, good behavior in the presence of restarts, and less
      waiting.  Improves high-settings openarena performance on my GM45 by 50%.
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
    • Eric Anholt's avatar
      drm/i915: Save/restore cursor state on suspend/resume. · 1fd1c624
      Eric Anholt authored
      This may fix cursor corruption in X on resume, which would persist until
      the cursor was hidden and then shown again.
      V2: Also include the cursor control regs.
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
    • Eric Anholt's avatar
      drm/i915: Remove a bad BUG_ON in the fence management code. · 0e7ddf7e
      Eric Anholt authored
      This could be triggered by a gtt mapping fault on 965 that decides to
      remove the fence from another object that happens to be active currently.
      Since the other object doesn't rely on the fence reg for its execution, we
      don't wait for it to finish.  We'll soon be not waiting on 915 most of the
      time as well, so just drop the BUG_ON.
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
  2. 29 May, 2009 1 commit
  3. 27 May, 2009 1 commit
    • Kristian Høgsberg's avatar
      i915: Set object to gtt domain when faulting it back in · 07f4f3e8
      Kristian Høgsberg authored
      When a GEM object is evicted from the GTT we set it to the CPU domain,
      as it might get swapped in and out or ever mmapped regularly.  If the
      object is mmapped through the GTT it can still get evicted in this way
      by other objects requiring GTT space.  When the GTT mapping is touched
      again we fault it back into the GTT, but fail to set it back to the
      GTT domain.  This means we fail to flush any cached CPU writes to the
      pages backing the object which will then happen "eventually", typically
      after we write to the page through the uncached GTT mapping.
      [anholt: Note that userland does do a set_domain(GTT, GTT) when starting
      to access the GTT mapping.  That covers getting the existing mapping of the
      object synchronized if it's bound to the GTT.  But set_domain(GTT, GTT)
      doesn't do anything if the object is currently unbound.  This fix covers the
      transition to being bound for GTT mapping.]
      Fixes glyph and other pixmap corruption during swapping.  fd.o bug #21790
      Signed-off-by: default avatarKristian Høgsberg <krh@redhat.com>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
  4. 26 May, 2009 3 commits
    • Eric Anholt's avatar
      drm/i915: Apply a big hammer to 865 GEM object CPU cache flushing. · cfa16a0d
      Eric Anholt authored
      On the 865, but not the 855, the clflush we do appears to not actually make
      it out to the hardware all the time.  An easy way to safely reproduce was
      X -retro, which would show that some of the blits involved in drawing the
      lovely root weave didn't make it out to the hardware.  Those blits are 32
      bytes each, and 1-2 would be missing at various points around the screen.
      Other experimentation (doing more clflush, doing more AGP chipset flush,
      poking at some more device registers to maybe trigger more flushing) didn't
      help.  krh came up with the wbinvd as a way to successfully get all those
      blits to appear.
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
    • Eric Anholt's avatar
      drm/i915: Fix tiling pitch handling on 8xx. · e76a16de
      Eric Anholt authored
      The pitch field is an exponent on pre-965, so we were rejecting buffers
      on 8xx that we shouldn't have.  915 got lucky in that the largest legal
      value happened to match (8KB / 512 = 0x10), but 8xx has a smaller tile width.
      Additionally, we programmed that bad value into the register on 8xx, so the
      only pitch that would work correctly was 4096 (512-1023 pixels), while others
      would probably give bad rendering or hangs.
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      fd.o bug #20473.
    • Ma Ling's avatar
      drm/i915: Add support for VGA load detection (pre-945). · e4a5d54f
      Ma Ling authored
      Two approaches for VGA detections: hot plug detection for 945G onwards
      and load pipe detection for Pre-945G.  Load pipe detection will get one free
      pipe, set border color as red and blue, then check CRT status by
      swf register.  This is a sync-up with the 2D driver.
      Signed-off-by: default avatarMa Ling <ling.ma@intel.com>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
  5. 22 May, 2009 5 commits
  6. 20 May, 2009 1 commit
  7. 19 May, 2009 2 commits
    • Benjamin Herrenschmidt's avatar
      drm: Round size of SHM maps to PAGE_SIZE · b6741377
      Benjamin Herrenschmidt authored
      Currently, userspace can fail to obtain the SAREA mapping (among other
      reasons) if it passes SAREA_MAX to drmAddMap without aligning it to the
      page size. This breaks for example on PowerPC with 64K pages and radeon
      despite the kernel radeon actually doing the right rouding in the first
      The way SAREA_MAX is defined with a bunch of ifdef's and duplicated
      between libdrm and the X server is gross, ultimately it should be
      retrieved by userspace from the kernel, but in the meantime, we have
      plenty of existing userspace built with bad values that need to work.
      This patch works around broken userspace by rounding the requested size
      in drm_addmap_core() of any SHM map to the page size. Since the backing
      memory for SHM maps is also allocated within addmap_core, there is no
      danger of adjacent memory being exposed due to the increased map size.
      The only side effect is that drivers that previously tried to create or
      access SHM maps using a size < PAGE_SIZE and failed (getting -EINVAL),
      will now succeed at the cost of a little bit more memory used if that
      happens to be when the map is created.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
    • Jesse Barnes's avatar
      drm/i915: allocate large pointer arrays with vmalloc · 8e7d2b2c
      Jesse Barnes authored
      For awhile now, many of the GEM code paths have allocated page or
      object arrays with the slab allocator.  This is nice and fast, but
      won't work well if memory is fragmented, since the slab allocator works
      with physically contiguous memory (i.e. order > 2 allocations are
      likely to fail fairly early after booting and doing some work).
      This patch works around the issue by falling back to vmalloc for
      >PAGE_SIZE allocations.  This is ugly, but much less work than chaining
      a bunch of pages together by hand (suprisingly there's not a bunch of
      generic kernel helpers for this yet afaik).  vmalloc space is somewhat
      precious on 32 bit kernels, but our allocations shouldn't be big enough
      to cause problems, though they're routinely more than a page.
      Note that this patch doesn't address the unchecked
      alloc-based-on-ioctl-args in GEM; that needs to be fixed in a separate
      Also, I've deliberately ignored the DRM's "area" junk.  I don't think
      anyone actually uses it anymore and I'm hoping it gets ripped out soon.
      [Updated: removed size arg to new free function.  We could unify the
      free functions as well once the DRM mem tracking is ripped out.]
      fd.o bug #20152 (part 1/3)
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
  8. 15 May, 2009 2 commits
  9. 14 May, 2009 8 commits
  10. 12 May, 2009 1 commit
  11. 05 May, 2009 1 commit
  12. 30 Apr, 2009 2 commits
  13. 23 Apr, 2009 7 commits
  14. 21 Apr, 2009 3 commits