Re: [PATCH 00/24] PPGTT dynamic page allocations

[Daniel Vetter <daniel@ffwll.ch>]

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@lists.freedesktop.org
> 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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx