[Intel-gfx] [PATCH 00/13] gen8 ppgtt dynamic page allocations

Daniel Vetter daniel at ffwll.ch
Thu Apr 9 05:19:39 PDT 2015


On Thu, Apr 09, 2015 at 10:14:49AM +0300, Mika Kuoppala wrote:
> Michel Thierry <michel.thierry at intel.com> writes:
> 
> > These are the last remining patches to enable dynamic allocation in gen8+.
> > All credit to Ben's original design and Mika's extensive reviews.
> >
> > During stress testing, the light restore context corruption problem was
> > observed in some systems (resubmission with HEAD==TAIL). The workaround to
> > prevent to prevent this known problem should be in place as we also update
> > the PDPx registers before the context is send to execution.
> >
> > The last patch is only of interest in systems with less than 4GB of memory.
> > Now that the PPGTT table overhead is not that big, we can use the full virtual
> > space address range in these systems.
> >
> > Michel Thierry (13):
> >   drm/i915: Remove _entry from PPGTT page structures
> >   drm/i915: Remove unnecessary gen8_ppgtt_unmap_pages
> >   drm/i915/gen8: Initialize page tables
> >   drm/i915/gen8: Add dynamic allocation macros and helper functions
> >   drm/i915/gen8: page directories rework allocation
> >   drm/i915/gen8: pagetable allocation rework
> >   drm/i915/gen8: 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 page_directory alloc
> >   drm/i915/gen8: Split out mappings
> >   drm/i915/gen8: begin bitmap tracking
> >   drm/i915/gen8: Dynamic page table allocations
> >   drm/i915: Use complete address space in true PPGTT
> >
> 
> Patches 1-13,
> Reviewed-by: Mika Kuoppala <mika.kuoppala at intel.com>

Merged the entire patch series, thanks. A few things to take care of once
this settles a bit (i.e. after the 48b stuff is merged):
- checkpatch wasn't too happy about the line breaks and long lines and
  stuff in here. But there's already a bit of that going on, so I figured
  a checkpatch pass over i915_gem_gtt.[hc] at the end is easier.
- A lot of the comments are now outdated, there's full-blown kerneldoc
  comments for static functions (which we generally don't do, that should
  all be evident from context) and I guess the existing kerneldoc also
  needs updating.
- i915_gem_gtt.h has way too many static inline functions. gcc will do a
  better job. Imo those should all/most be moved into i915_gem_gtt.c.
- i915_gem_gtt.c has a bunch of unecessary forward declarations.

Anyway just polish.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list