1. 20 Sep, 2012 3 commits
  2. 27 Aug, 2012 1 commit
    • Sedat Dilek's avatar
      drm/i915: Remove __GFP_NO_KSWAPD · d7c3b937
      Sedat Dilek authored
      When I pulled-in today's drm-intel-next into linux-next (next-20120824)
      I saw this build-breakage:
      drivers/gpu/drm/i915/i915_gem.c: In function 'i915_gem_object_get_pages_gtt':
      drivers/gpu/drm/i915/i915_gem.c:1778:40: error: '__GFP_NO_KSWAPD' undeclared (first use in this function)
      drivers/gpu/drm/i915/i915_gem.c:1778:40: note: each undeclared identifier is reported only once for each function it appears in
      This is caused by commit ba099ef165f8 ("mm: remove __GFP_NO_KSWAPD")
      and commit b6beae2c2014 ("mm: remove __GFP_NO_KSWAPD fixes") in
      linux-next (next-20120824).
      Fix this by removing __GFP_NO_KSWAPD from drm/i915 driver.
      Signed-off-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  3. 24 Aug, 2012 2 commits
    • Chris Wilson's avatar
      drm/i915: Use a non-blocking wait for set-to-domain ioctl · 3236f57a
      Chris Wilson authored
      The principal use for set-to-domain is for userspace to serialise
      operations with a particular buffer, for example to maintain coherency
      with a CPU map or to ratelimit its rendering by waiting on all previous
      operations before continuing. As such we tend to hold the struct_mutex
      for long periods during the synchronisation and so cause contention
      issues with other users of the graphics device, even for independent
      operations as memory management. An example is the contention between
      compiz and X which causes jitter in the display and a drop in peak
      The ultimate solution would be a set of fine grained locks and lockless
      operations, but an intermediate step is to first attempt the
      synchronisation for set-to-domain without holding the mutex. This
      introduces a number of race conditions, so we limit it use to the ioctl
      periphery where we have no dependent state and can safely complete with
      a locked synchronisation afterwards.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Chris Wilson's avatar
      drm/i915: Juggle code order to ease flow of the next patch · b361237b
      Chris Wilson authored
      Move the wait-for-rendering logic around in the file so that we can
      group it together with the subsequent variations. The general goal is to
      have the lower level routines clustered together and then the higher
      level logic building upon those low level routines that came before.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  4. 23 Aug, 2012 3 commits
  5. 21 Aug, 2012 3 commits
    • Chris Wilson's avatar
      drm/i915: Try harder to allocate an mmap_offset · d8cb5086
      Chris Wilson authored
      Given the persistence of an offset for the lifetime of an object, itis
      easy to contemplate how the mmap space becomes badly fragmented to the
      point that further allocations fail with ENOSPC. Our only recourse at
      this point is to try to purge the objects to release some space and
      reattempt the allocation.
      References: https://bugs.freedesktop.org/show_bug.cgi?id=39552
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Chris Wilson's avatar
      drm/i915: Add some sanity checks to unbound tracking · c4670ad0
      Chris Wilson authored
      A pair of universally true checks that just need to be put in the right
      place depending on where in the patch sequence you go. Note that
      i915_gem_object_put_pages_gtt() already gains the
      BUG_ON(obj->gtt_space), but on reflection that needed to migrate to
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Chris Wilson's avatar
      drm/i915: Track unbound pages · 6c085a72
      Chris Wilson authored
      When dealing with a working set larger than the GATT, or even the
      mappable aperture when touching through the GTT, we end up with evicting
      objects only to rebind them at a new offset again later. Moving an
      object into and out of the GTT requires clflushing the pages, thus
      causing a double-clflush penalty for rebinding.
      To avoid having to clflush on rebinding, we can track the pages as they
      are evicted from the GTT and only relinquish those pages on memory
      As usual, if it were not for the handling of out-of-memory condition and
      having to manually shrink our own bo caches, it would be a net reduction
      of code. Alas.
      Note: The patch also contains a few changes to the last-hope
      evict_everything logic in i916_gem_execbuffer.c - we no longer try to
      only evict the purgeable stuff in a first try (since that's superflous
      and only helps in OOM corner-cases, not fragmented-gtt trashing
      Also, the extraction of the get_pages retry loop from bind_to_gtt (and
      other callsites) to get_pages should imo have been a separate patch.
      v2: Ditch the newly added put_pages (for unbound objects only) in
      i915_gem_reset. A quick irc discussion hasn't revealed any important
      reason for this, so if we need this, I'd like to have a git blame'able
      explanation for it.
      v3: Undo the s/drm_malloc_ab/kmalloc/ in get_pages that Chris noticed.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      [danvet: Split out code movements and rant a bit in the commit message
      with a few Notes. Done v2]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  6. 20 Aug, 2012 1 commit
  7. 17 Aug, 2012 1 commit
  8. 10 Aug, 2012 1 commit
    • Chris Wilson's avatar
      drm/i915: Lazily apply the SNB+ seqno w/a · b2eadbc8
      Chris Wilson authored
      Avoid the forcewake overhead when simply retiring requests, as often the
      last seen seqno is good enough to satisfy the retirment process and will
      be promptly re-run in any case. Only ensure that we force the coherent
      seqno read when we are explicitly waiting upon a completion event to be
      sure that none go missing, and also for when we are reporting seqno
      values in case of error or debugging.
      This greatly reduces the load for userspace using the busy-ioctl to
      track active buffers, for instance halving the CPU used by X in pushing
      the pixels from a software render (flash). The effect will be even more
      magnified with userptr and so providing a zero-copy upload path in that
      instance, or in similar instances where X is simply compositing DRI
      v2: Reverse the polarity of the tachyon stream. Daniel suggested that
      'force' was too generic for the parameter name and that 'lazy_coherency'
      better encapsulated the semantics of it being an optimization and its
      purpose. Also notice that gen6_get_seqno() is only used by gen6/7
      chipsets and so the test for IS_GEN6 || IS_GEN7 is redundant in that
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  9. 26 Jul, 2012 2 commits
    • Chris Wilson's avatar
      drm/i915: Export ability of changing cache levels to userspace · e6994aee
      Chris Wilson authored
      By selecting the cache level (essentially whether or not the CPU snoops
      any updates to the bo, and on more recent machines whether it resides
      inside the CPU's last-level-cache) a userspace driver is able to then
      manage all of its memory within buffer objects, if it so desires. This
      enables the userspace driver to accelerate uploads and more importantly
      downloads from the GPU and to able to mix CPU and GPU rendering/activity
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      [danvet: Added code comment about where we plan to stuff platform
      specific cacheing control bits in the ioctl struct.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Chris Wilson's avatar
      drm/i915: Segregate memory domains in the GTT using coloring · 42d6ab48
      Chris Wilson authored
      Several functions of the GPU have the restriction that differing memory
      domains cannot be placed next to each other (as the GPU may prefetch
      beyond the end of one domain and hang as it crosses into the other
      domain). We use the facility of the drm_mm to mark ranges with a
      particular color that corresponds to the cache attributes of those pages
      in order to prevent allocating adjacent blocks of differing memory
      v2: Rebase ontop of drm_mm coloring v2.
      v3: Fix rebinding existing gtt_space and add a verification routine.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  10. 25 Jul, 2012 11 commits
  11. 20 Jul, 2012 1 commit
  12. 15 Jul, 2012 1 commit
    • Chris Wilson's avatar
      drm: Add colouring to the range allocator · 6b9d89b4
      Chris Wilson authored
      In order to support snoopable memory on non-LLC architectures (so that
      we can bind vgem objects into the i915 GATT for example), we have to
      avoid the prefetcher on the GPU from crossing memory domains and so
      prevent allocation of a snoopable PTE immediately following an uncached
      PTE. To do that, we need to extend the range allocator with support for
      tracking and segregating different node colours.
      This will be used by i915 to segregate memory domains within the GTT.
      v2: Now with more drm_mm helpers and less driver interference.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Dave Airlie <airlied@redhat.com
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@gmail.com>
  13. 05 Jul, 2012 3 commits
    • Daniel Vetter's avatar
      drm/i915: properly SIGBUS on I/O errors · a9340cca
      Daniel Vetter authored
      ... instead of looping endless with no hope of ever serving that
      page-fault. We only need to break out of this loop when the gpu died,
      to run the reset work (and hopefully resurrect it).
      To clarify questions Chris raised on irc: This is about handling I/O
      errors not from our own code, but e.g. when the disk died when trying
      to swap in a gem bo. So this patch remidies the issue that the current
      handling only handles gpu-death-induced cases of -EIO. Admittedly,
      dying disks are much rarer than hanging gpus ...To clarify questions
      Chris raised on irc: This is about handling I/O errors not from our
      own code, but e.g. when the disk died when trying to swap in a gem bo.
      So this patch remidies the issue that the current handling only
      handles gpu-death-induced cases of -EIO. Admittedly, dying disks are
      much rarer than hanging gpus ...
      This seems to have been lost in:
      commit d9bc7e9f
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Mon Feb 7 13:09:31 2011 +0000
          drm/i915: Fix infinite loop regression from 21dd3734
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Daniel Vetter's avatar
      drm/i915: don't hang userspace when the gpu reset is stuck · 0a6759c6
      Daniel Vetter authored
      With the gpu reset no longer using a trylock we've increased the
      chances of userspace getting stuck quite a bit. To make that
      (hopefully) rare case more paletable time out when waiting for the gpu
      reset code to complete and signal this little issue to the caller by
      returning -EIO.
      This should help userspace to somewhat gracefully fall back and
      hopefully allow the user to grab some logs and reboot the machine
      (instead of staring at a frozen X screen in agony).
      Suggested by Chris Wilson because I've been stubborn about allowing
      the gpu reset code no to fail, ever (by removing the trylock).
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Daniel Vetter's avatar
      drm/i915: non-interruptible sleeps can't handle -EAGAIN · d6b2c790
      Daniel Vetter authored
      So don't return -EAGAIN, even in the case of a gpu hang. Remap it to
      -EIO instead. Note that this isn't really an issue with
      interruptability, but more that we have quite a few codepaths (mostly
      around kms stuff) that simply can't handle any errors and hence not
      even -EAGAIN. Instead of adding proper failure paths so that we could
      restart these ioctls we've opted for the cheap way out of sleeping
      non-interruptibly.  Which works everywhere but when the gpu dies,
      which this patch fixes.
      So essentially interruptible == false means 'wait for the gpu or die
      This patch is a bit ugly because intel_ring_begin is all non-interruptible
      and hence only returns -EIO. But as the comment in there says,
      auditing all the callsites would be a pain.
      To avoid duplicating code, reuse i915_gem_check_wedge in __wait_seqno
      and intel_wait_ring_buffer. Also use the opportunity to clarify the
      different cases in i915_gem_check_wedge a bit with comments.
      v2: Don't access dev_priv->mm.interruptible from check_wedge - we
      might not hold dev->struct_mutex, making this racy. Instead pass
      interruptible in as a parameter. I've noticed this because I've hit a
      BUG_ON(!mutex_is_locked) at the top of check_wedge. This has been
      added in
      commit b4aca010
      Author: Ben Widawsky <ben@bwidawsk.net>
      Date:   Wed Apr 25 20:50:12 2012 -0700
          drm/i915: extract some common olr+wedge code
      although that commit is missing any justification for this. I guess
      it's just copy&paste, because the same commit add the same BUG_ON
      check to check_olr, where it indeed makes sense.
      But in check_wedge everything we access is protected by other means,
      so this is superflous. And because it now gets in the way (we add a
      new caller in __wait_seqno, which can be called without
      dev->struct_mutext) let's just remove it.
      v3: Group all the i915_gem_check_wedge refactoring into this patch, so
      that this patch here is all about not returning -EAGAIN to callsites
      that can't handle syscall restarting.
      v4: Add clarification what interuptible == fales means in our code,
      requested by Ben Widawsky.
      v5: Fix EAGAIN mispell noticed by Chris Wilson.
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  14. 20 Jun, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: disable flushing_list/gpu_write_list · cc889e0f
      Daniel Vetter authored
      This is just the minimal patch to disable all this code so that we can
      do decent amounts of QA before we rip it all out.
      The complicating thing is that we need to flush the gpu caches after
      the batchbuffer is emitted. Which is past the point of no return where
      execbuffer can't fail any more (otherwise we risk submitting the same
      batch multiple times).
      Hence we need to add a flag to track whether any caches associated
      with that ring are dirty. And emit the flush in add_request if that's
      the case.
      Note that this has a quite a few behaviour changes:
      - Caches get flushed/invalidated unconditionally.
      - Invalidation now happens after potential inter-ring sync.
      I've bantered around a bit with Chris on irc whether this fixes
      anything, and it might or might not. The only thing clear is that with
      these changes it's much easier to reason about correctness.
      Also rip out a lone get_next_request_seqno in the execbuffer
      retire_commands function. I've dug around and I couldn't figure out
      why that is still there, with the outstanding lazy request stuff it
      shouldn't be necessary.
      v2: Chris Wilson complained that I also invalidate the read caches
      when flushing after a batchbuffer. Now optimized.
      v3: Added some comments to explain the new flushing behaviour.
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  15. 14 Jun, 2012 2 commits
    • Ben Widawsky's avatar
      drm/i915: switch to default context on idle · f2ef6eb1
      Ben Widawsky authored
      To keep things as sane as possible, switch to the default context before
      idling. This should help free context objects, as well as put things in
      a more well defined state before suspending.
      v2: remove seqno from context switch call (daniel)
      return error on failed context switch instead of WARN+continue (daniel)
      v3: move idling to i915_gpu idle (from i915_gem_idle) (Chris)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
    • Ben Widawsky's avatar
      drm/i915: preliminary context support · 254f965c
      Ben Widawsky authored
      Very basic code for context setup/destruction in the driver.
      Adds the file i915_gem_context.c This file implements HW context
      support. On gen5+ a HW context consists of an opaque GPU object which is
      referenced at times of context saves and restores.  With RC6 enabled,
      the context is also referenced as the GPU enters and exists from RC6
      (GPU has it's own internal power context, except on gen5).  Though
      something like a context does exist for the media ring, the code only
      supports contexts for the render ring.
      In software, there is a distinction between contexts created by the
      user, and the default HW context. The default HW context is used by GPU
      clients that do not request setup of their own hardware context. The
      default context's state is never restored to help prevent programming
      errors. This would happen if a client ran and piggy-backed off another
      clients GPU state.  The default context only exists to give the GPU some
      offset to load as the current to invoke a save of the context we
      actually care about. In fact, the code could likely be constructed,
      albeit in a more complicated fashion, to never use the default context,
      though that limits the driver's ability to swap out, and/or destroy
      other contexts.
      All other contexts are created as a request by the GPU client. These
      contexts store GPU state, and thus allow GPU clients to not re-emit
      state (and potentially query certain state) at any time. The kernel
      driver makes certain that the appropriate commands are inserted.
      There are 4 entry points into the contexts, init, fini, open, close.
      The names are self-explanatory except that init can be called during
      reset, and also during pm thaw/resume. As we expect our context to be
      preserved across these events, we do not reinitialize in this case.
      As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
      considered too big is arbitrary. The reason for this is even though
      context sizes are increasing with every generation, they have yet to
      eclipse even 32k. If we somehow read back way more than that, it
      probably means BIOS has done something strange, or we're running on a
      platform that wasn't designed for this.
      v2: rename load/unload to init/fini (daniel)
      remove ILK support for get_size() (indirectly daniel)
      add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
      added comments (Ben)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
  16. 12 Jun, 2012 2 commits
  17. 06 Jun, 2012 1 commit
    • Ben Widawsky's avatar
      drm/i915: Inifite timeout for wait ioctl · eac1f14f
      Ben Widawsky authored
      Change the ns_timeout parameter of the wait ioctl to a signed value.
      Doing this allows the kernel to provide an infinite wait when a timeout
      of less than 0 is provided. This mimics select/poll.
      Initially the parameter was meant to match up with the GL spec 1:1, but
      after being made aware of how much 2^64 - 1 nanoseconds actually is, I
      do not think anyone will ever notice the loss of 1 bit.
      The infinite timeout on waiting is similar to the existing i915
      userspace interface with the exception that struct_mutex is dropped
      while doing the wait in this ioctl.
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  18. 02 Jun, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: extract object active state flushing code · 30dfebf3
      Daniel Vetter authored
      Both busy_ioctl and the new wait_ioct need to do the same dance (or at
      least should). Some slight changes:
      - busy_ioctl now unconditionally checks for olr. Before emitting a
        require flush would have prevent the olr check and hence required a
        second call to the busy ioctl to really emit the request.
      - the timeout wait now also retires request. Not really required for
        abi-reasons, but makes a notch more sense imo.
      I've tested this by pimping the i-g-t test some more and also checking
      the polling behviour of the wait_rendering_timeout ioctl versus what
      busy_ioctl returns.
      v2: Too many people complained about unplug, new color is
      v3: Kill the comment about the unplug moniker.
      v4: s/un-active/inactive/
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>