1. 23 Aug, 2012 1 commit
  2. 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>
      d8cb5086
    • 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
      put_pages().
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c4670ad0
    • 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
      pressure.
      
      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
      situations).
      
      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>
      6c085a72
  3. 20 Aug, 2012 1 commit
  4. 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
      buffers.
      
      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
      function.
      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>
      b2eadbc8
  5. 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
      efficiently.
      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>
      e6994aee
    • 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
      types.
      
      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>
      42d6ab48
  6. 25 Jul, 2012 11 commits
  7. 20 Jul, 2012 1 commit
  8. 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>
      6b9d89b4
  9. 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>
      a9340cca
    • 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>
      0a6759c6
    • 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
      trying'.'
      
      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>
      d6b2c790
  10. 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>
      cc889e0f
  11. 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>
      f2ef6eb1
    • 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>
      254f965c
  12. 12 Jun, 2012 2 commits
  13. 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>
      eac1f14f
  14. 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
      flush_active.
      
      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>
      30dfebf3
  15. 31 May, 2012 1 commit
  16. 25 May, 2012 5 commits
    • Ben Widawsky's avatar
      drm/i915: s/i915_wait_request/i915_wait_seqno/g · 199b2bc2
      Ben Widawsky authored
      
      
      Wait request is poorly named IMO. After working with these functions for
      some time, I feel it's much clearer to name the functions more
      appropriately.
      
      Of course we must update the callers to use the new name as well.
      
      This leaves room within our namespace for a *real* wait request function
      at some point.
      
      Note to maintainer: this patch is optional.
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      199b2bc2
    • Ben Widawsky's avatar
      drm/i915: wait render timeout ioctl · 23ba4fd0
      Ben Widawsky authored
      
      
      This helps implement GL_ARB_sync but stops short of allowing full blown
      sync objects. Finally we can use the new timed seqno waiting function
      to allow userspace to wait on a buffer object with a timeout. This
      implements that interface.
      
      The IOCTL will take as input a buffer object handle, and a timeout in
      nanoseconds (flags is currently optional but will likely be used for
      permutations of flush operations). Users may specify 0 nanoseconds to
      instantly check.
      
      The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any
      non-zero timeout parameter the wait ioctl will wait for the given number
      of nanoseconds on an object becoming unbusy. Since the wait itself does
      so holding struct_mutex the object may become re-busied before this
      completes. A similar but shorter race condition exists in the busy
      ioctl.
      
      v2: ETIME/ERESTARTSYS instead of changing to EBUSY, and EGAIN (Chris)
      Flush the object from the gpu write domain (Chris + Daniel)
      Fix leaked refcount in good case (Chris)
      Naturally align ioctl struct (Chris)
      
      v3: Drop lock after getting seqno to avoid ugly dance (Chris)
      
      v4: check for 0 timeout after olr check to allow polling (Chris)
      
      v5: Updated the comment. (Chris)
      
      v6: Return -ETIME instead of -EBUSY when timeout_ns is 0 (Daniel)
      Fix the commit message comment to be less ugly (Ben)
      Add a warning to check the return timespec (Ben)
      
      v7: Use DRM_AUTH for the ioctl. (Eugeni)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      23ba4fd0
    • Chris Wilson's avatar
      drm/i915: Remove the error message for unbinding pinned buffers · 31d8d651
      Chris Wilson authored
      This is now used intentionally to prevent proliferation of is-pinned
      checks upon the inactive list following:
      
      commit 1b50247a
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Apr 24 15:47:30 2012 +0100
      
          drm/i915: Remove the list of pinned inactive objects
      
      Reported-and-tested-by: guang.a.yang@intel.com
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50075
      
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      31d8d651
    • Chris Wilson's avatar
      drm/i915: Limit page allocations to lowmem (dma32) for i965 · bed1ea95
      Chris Wilson authored
      
      
      Broadwater and Crestline share a limitation that prevent it from
      relocating general surface state above 4GiB. The only recourse we have
      since any buffer object may be used as a relocation target is then to
      limit all object allocations on 965g[m] to DMA32.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      bed1ea95
    • Ben Widawsky's avatar
      drm/i915: timeout parameter for seqno wait · 5c81fe85
      Ben Widawsky authored
      
      
      Insert a wait parameter in the code so we can possibly timeout on a
      seqno wait if need be. The code should be functionally the same as
      before because all the callers will continue to retry if an arbitrary
      timeout elapses.
      
      We'd like to have nanosecond granularity, but the only way to do this is
      with hrtimer, and that doesn't fit well with the needs of this code.
      
      v2: Fix rebase error (Chris)
      Return proper time even in wedged + signal case (Chris + Ben)
      Use timespec constructs (Ben)
      Didn't take Daniel's advice regarding the Frankenstein-ness of the
        function. I did try his advice, but in the end I liked the way the
        original code looked, better.
      
      v3: Make wakeups far less frequent for infinite waits (Chris)
      
      v4: Remove dummy_wait variable (Daniel)
      Use raw monotonic time instead of jiffies (made the code a bit cleaner) (Ben)
      Added a couple of warnings (Ben)
      
      v5: Remove warnings (Daniel)
      Use more accurate time diff for default case (Daniel)
      Bikeshed for setting the return timespec in timeout case (Daniel)
      s/jiffies/time in one of the comments
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5c81fe85
  17. 23 May, 2012 1 commit
    • Daniel Vetter's avatar
      i915: add dmabuf/prime buffer sharing support. · 1286ff73
      Daniel Vetter authored
      
      
      This adds handle->fd and fd->handle support to i915, this is to allow
      for offloading of rendering in one direction and outputs in the other.
      
      v2 from Daniel Vetter:
      - fixup conflicts with the prepare/finish gtt prep work.
      - implement ppgtt binding support.
      
      Note that we have squat i-g-t testcoverage for any of the lifetime and
      access rules dma_buf/prime support brings along. And there are quite a
      few intricate situations here.
      
      Also note that the integration with the existing code is a bit
      hackish, especially around get_gtt_pages and put_gtt_pages. It imo
      would be easier with the prep code from Chris Wilson's unbound series,
      but that is for 3.6.
      
      Also note that I didn't bother to put the new prepare/finish gtt hooks
      to good use by moving the dma_buf_map/unmap_attachment calls in there
      (like we've originally planned for).
      
      Last but not least this patch is only compile-tested, but I've changed
      very little compared to Dave Airlie's version. So there's a decent
      chance v2 on drm-next works as well as v1 on 3.4-rc.
      
      v3: Right when I've hit sent I've noticed that I've screwed up one
      obj->sg_list (for dmar support) and obj->sg_table (for prime support)
      disdinction. We should be able to merge these 2 paths, but that's
      material for another patch.
      
      v4: fix the error reporting bugs pointed out by ickle.
      
      v5: fix another error, and stop non-gtt mmaps on shared objects
      stop pread/pwrite on imported objects, add fake kmap
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1286ff73
  18. 19 May, 2012 1 commit
    • Chris Wilson's avatar
      drm/i915: Introduce for_each_ring() macro · b4519513
      Chris Wilson authored
      
      
      In many places we wish to iterate over the rings associated with the
      GPU, so refactor them to use a common macro.
      
      Along the way, there are a few code removals that should be side-effect
      free and some rearrangement which should only have a cosmetic impact,
      such as error-state.
      
      Note that this slightly changes the semantics in the hangcheck code:
      We now always cycle through all enabled rings instead of
      short-circuiting the logic.
      
      v2: Pull in a couple of suggestions from Ben and Daniel for
      intel_ring_initialized() and not removing the warning (just moving them
      to a new home, closer to the error).
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      [danvet: Added note to commit message about the small behaviour
      change, suggested by Ben Widawsky.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b4519513
  19. 03 May, 2012 1 commit