[Intel-gfx] [PATCH 00/12] Completion of i915 VMAs

Ben Widawsky ben at bwidawsk.net
Mon Jul 22 04:08:07 CEST 2013


Included in this series are the unmerged patches from the VMA only
version of my post [1] as well as two new sets of patches on top. Daniel
has already merged the first part of the series which introduced the
VMAs, and VMs, but didn't actually use them ([2]).

As agreed up in the previous mail thread ([1]), I've put in a couple
things on top of the old series to make the end result what Daniel was
looking for; and I also agree it's an improvement. (One downside however
is I can no longer use the original 66 patch series [3] as a direct
reference) objective was to not throw away all the testing I had done on
the previous work, make the changes easier to review, but still get to
where we needed to get to.  The diff churn is a bit higher than if I had
just rebased it in.

The two big things this adds from the last go around are:
1. map/unmap_vma function pointers for the VM.
2. conversion of some <obj,vm> -> vma in functions.

Map, and unmap are logical functionalities to add for an address space.
They do more or less what you'd think: take an object and create a
mapping via the GPU's page tables to that object. Of course, without the
rest of the patches from [3], there will only ever be 1 address space,
with the weird aliasing ppgtt behind it. One thing which I toyed with,
but opted not to include was to directly pass obj,vm to map/unmap
instead of doing the slightly less pretty way as I've done in execbuf
and bind. In the future I think I may just do this, but for now it's not
a big win as the end result wasn't much better (and I didn't get it to
immediately work).

The conversion of <obj,vm> to VMA was a lot of churn, but the idea is
simple. In the original series [1,3], I passed the pair of an object and
an address space everywhere. Every time I needed to convert that into a
VMA, it requires walking a list. In fact, we only need to walk the list
once - GEM is still all about BOs, and I have no intention of changing
this - so we must walk the list at user space entry points; but from
thereon it can all be a VMA. The caveat is, we do have a few internal
APIs that are easily broken unless we talk in objects (caching is one of
them). As I mentioned in the original series, we may eventually want to
move things over to be all in the VMA. For now, I think this is fine as
it stands. You'll notice unbind() to be a wart currently - but the
alternative looked worse to my eyes.

Breakdown:
The first 4 patches are basically what I sent in [1], except I've
squashed some stuff, rebased, and applied some requested fixups, which
brought the patch count down from 6->4.

The next 3 patches are about the map/unmap mentioned in #1.

And the final 5 patches are for replacing <obj,vm> pairs with vma, #2.

Testing:
IGT looks pretty stable on IVB. I was having a lot of issues on gpu reset
on my ILK, but somehow after a clean build, I stopped seeing it. I've
done nothing else.

References:
[1] http://lists.freedesktop.org/archives/intel-gfx/2013-July/029974.html
[2] http://lists.freedesktop.org/archives/intel-gfx/2013-July/030395.html
[3] http://lists.freedesktop.org/archives/intel-gfx/2013-June/029408.html

I've pushed a badly rebased onto -nightly here (not worth fixing):
http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=ppgtt2

---

Ben Widawsky (12):
  drm/i915: plumb VM into object operations
  drm/i915: Fix up map and fenceable for VMA
  drm/i915: Update error capture for VMs
  drm/i915: Track active by VMA instead of object
  drm/i915: Add map/unmap object functions to VM
  drm/i915: Use the new vm [un]bind functions
  drm/i915: eliminate vm->insert_entries()
  drm/i915: Add vma to list at creation
  drm/i915: create vmas at execbuf
  drm/i915: Convert execbuf code to use vmas
  drm/i915: Convert object coloring to VMA
  drm/i915: Convert active API to VMA

 drivers/gpu/drm/i915/i915_debugfs.c        |  68 +++--
 drivers/gpu/drm/i915/i915_dma.c            |   4 -
 drivers/gpu/drm/i915/i915_drv.h            | 193 +++++++------
 drivers/gpu/drm/i915/i915_gem.c            | 433 ++++++++++++++++++++---------
 drivers/gpu/drm/i915/i915_gem_context.c    |  17 +-
 drivers/gpu/drm/i915/i915_gem_evict.c      |  78 +++---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 321 +++++++++++----------
 drivers/gpu/drm/i915/i915_gem_gtt.c        | 140 ++++++----
 drivers/gpu/drm/i915/i915_gem_stolen.c     |  10 +-
 drivers/gpu/drm/i915/i915_gem_tiling.c     |  10 +-
 drivers/gpu/drm/i915/i915_gpu_error.c      | 111 +++++---
 drivers/gpu/drm/i915/i915_trace.h          |  20 +-
 drivers/gpu/drm/i915/intel_fb.c            |   1 -
 drivers/gpu/drm/i915/intel_overlay.c       |   2 +-
 drivers/gpu/drm/i915/intel_pm.c            |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c    |  16 +-
 16 files changed, 880 insertions(+), 546 deletions(-)

-- 
1.8.3.3




More information about the Intel-gfx mailing list