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
