On Thu, Dec 18, 2014 at 05:09:57PM +0000, Michel Thierry wrote: > This new version tries to remove as many unnecessary changes as possible from > the previous RFC. > > For GEN8, it has also been extended to work in logical ring submission (lrc) > mode, as it will be the preferred mode of operation. > I also tried to update the lrc code at the same time the ppgtt refactoring > occurred, leaving only one patch that is exclusively for lrc. > > This list can be seen in 3 parts: > [01-10] Include code rework for PPGTT (all GENs). > [11-14] Adds page table allocation for GEN6/GEN7 > [15-24] Enables dynamic allocation in GEN8. It is enabled for both legacy > and execlist submission modes. > > Ben Widawsky (23): > drm/i915: Add some extra guards in evict_vm > drm/i915/trace: Fix offsets for 64b > drm/i915: Rename to GEN8_LEGACY_PDPES > drm/i915: Setup less PPGTT on failed pagedir > drm/i915/gen8: Un-hardcode number of page directories > drm/i915: Range clearing is PPGTT agnostic > drm/i915: page table abstractions > drm/i915: Complete page table structures > drm/i915: Create page table allocators > drm/i915: Track GEN6 page table usage > drm/i915: Extract context switch skip logic > drm/i915: Track page table reload need > drm/i915: Initialize all contexts > drm/i915: Finish gen6/7 dynamic page table allocation > drm/i915/bdw: Use dynamic allocation idioms on free > drm/i915/bdw: pagedirs rework allocation > drm/i915/bdw: pagetable allocation rework > drm/i915/bdw: Update pdp switch and point unused PDPs to scratch page > drm/i915: num_pd_pages/num_pd_entries isn't useful > drm/i915: Extract PPGTT param from pagedir alloc > drm/i915/bdw: Split out mappings > drm/i915/bdw: begin bitmap tracking > drm/i915/bdw: Dynamic page table allocations > > Michel Thierry (1): > drm/i915/bdw: Dynamic page table allocations in lrc mode Ok, I've tried to read through this series again and I definitely see a bit clearer, but it's still fairly confusing to me. I think that's just the long history of this patch series - often it seems to do something and then undo it again in some later patch. Which doesn't help understanding it. I've replied with a few comments. Imo the way forward with this is to read, understand and review it from the beginning and merge while that's happening. It will probably take a few rounds until all the confusion is cleared up and we've reached the last patch. -Daniel > > drivers/gpu/drm/i915/i915_debugfs.c | 7 +- > drivers/gpu/drm/i915/i915_drv.h | 7 + > drivers/gpu/drm/i915/i915_gem_context.c | 62 +- > drivers/gpu/drm/i915/i915_gem_evict.c | 3 + > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 + > drivers/gpu/drm/i915/i915_gem_gtt.c | 1224 ++++++++++++++++++++-------- > drivers/gpu/drm/i915/i915_gem_gtt.h | 252 +++++- > drivers/gpu/drm/i915/i915_trace.h | 124 ++- > drivers/gpu/drm/i915/intel_lrc.c | 80 +- > 9 files changed, 1378 insertions(+), 392 deletions(-) > > -- > 2.1.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
