[PATCH 00/12] [RFC] PPGTT prep patches part 1

[Ben Widawsky <ben@bwidawsk.net>]

First, I have not finished implementing PPGTT. These are all the patches
I have which I can dump now and not have serious regression risk (and I
think most of them are tolerable on their own). The point is to get
review, make my plans explicit, and get these patches merged.

The main accomplishment of this series is to provide more abstract
management of the PPGTT for when we have more than just the aliasing
PPGTT. That abstract way in which we allocate space for PPGTT PDEs (and
the use of the topdown allocator for that matter) seem entirely
unnecessary because of course nothing has functionally changed except
the ppgtt is not kzalloc'd, and that PDEs now serve as the guard page
now for gen6+  (y'all own me 4k).

I've seriously reworked Chris' top down allocator patch, so I'd really
like at least him to take a look at that one and make sure he still
agrees.

Since the earliest discussions of contexts in early 2011, we've
discussed the association between a context and the PPGTT. I've always
felt it made sense to have a very strong association between a context
and its address space. Knowing a bit about the future, I feel doubly
confident in saying so. Aside from the reworks in this series which
allows PPGTT PDE allocation to come from the drm_mm allocator, the rest
irrevocably ties the PPGTT to a context, and one cannot exist without
the other.  Future patcher in the later series' will make things fail a
lot harder if one exists without the other.

Even those these patches don't yet do the following, I should explain
the next steps or else I feel reviewers' comments to the above will all
be, "why?"
1. Create a new context/ppgtt for every file_priv.
2. Instruct execbuffer/reserve code to use that file_priv context
3. Switch PP_DIR_BASE on context switch.
This will likely be where I post part 2 of the prep patches, and I do
not expect to merge those before the rest of the series is complete. At
that point flink, dma_buf,  and pin interfaces won't work. It should
however prove a useful way to test the HW pretty well. It also shows how
I intend to have a per file context/address space regardless of whether
or not userspace opts in.

4. Track objects across address spaces
This should enable flink and dma_buf to work. I suspect a lot of
bikeshedding will take place on this patch(es) so I want to make it
distinct from the HW testing.

5. Figure out what do about killing relocations.

6. PPGTT page tables allocated on demand

For the curious reader, I've implemented 1, 2, and 4 several times over the
past couple of weeks. I was using MI_UPDATE_GTT for step 3 originally, and that
was tested as well, but I haven't yet done the PP_DIR_BASE switch since
implementing the drm_mm for PDEs.

I haven't run performance numbers on this series specifically, but I did
run performance numbers on the slightly more invasive patches which come
after (through step 1 above)

x11perf -aa10text
before: 1925000/s
after:  1941667/s (clearly not a good test)

xonotic
before: 140.6242469 fps
after:  138.5189648 fps


Ben Widawsky (11):
  drm/i915: Assert mutex_is_locked on context lookup
  drm/i915: BUG_ON bad PPGTT offset
  drm/i915: make PDE|PTE platform specific
  drm/i915: Extract PDE writes
  drm/i915: Use drm_mm for PPGTT PDEs
  drm/i915: Use PDEs as the guard page
  drm/i915: Update context_fini
  drm/i915: Split context enabling from init
  drm/i915: destroy i915_gem_init_global_gtt
  drm/i915: Embed PPGTT into the context
  drm/i915: No contexts without ppgtt

Chris Wilson (1):
  drm: Optionally create mm blocks from top-to-bottom

 drivers/gpu/drm/drm_mm.c                |  94 +++++++++++---------
 drivers/gpu/drm/i915/i915_dma.c         |   2 +-
 drivers/gpu/drm/i915/i915_drv.h         |  15 ++--
 drivers/gpu/drm/i915/i915_gem.c         |  49 +++++++++--
 drivers/gpu/drm/i915/i915_gem_context.c |  33 ++++---
 drivers/gpu/drm/i915/i915_gem_gtt.c     | 147 ++++++++++++++++----------------
 include/drm/drm_mm.h                    |  78 +++++++++++------
 7 files changed, 251 insertions(+), 167 deletions(-)

-- 
1.8.2.1