On Wed, Jan 11, 2017 at 02:04:53PM +0200, Joonas Lahtinen wrote: > On ke, 2017-01-11 at 11:23 +0000, Chris Wilson wrote: > > When we evict from the GTT to make room for an object, the hole we > > create is put onto the MRU stack inside the drm_mm range manager. On the > > next search pass, we can speed up a PIN_HIGH allocation by referencing > > that stack for the new hole. > > > > v2: Pull together the 3 identical implements (ahem, a couple were > > outdated) into a common routine for allocating a node and evicting as > > necessary. > > v3: Detect invalid calls to i915_gem_gtt_insert() > > v4: kerneldoc > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > > <SNIP> > > > +/** > > + * i915_gem_gtt_insert - insert a node into an address_space (GTT) > > + * @vm - the &struct i915_address_space > > mixing &struct and @struct, I guess you meant &struct in later line > too. > > > + * @node - the @struct drm_mm_node (typicallay i915_vma.mode) > > "typicallly" and "i915_vma.node" > > > + * @size - how much space to allocate inside the GTT, > > + * must be #I915_GTT_PAGE_SIZE aligned > > + * @alignment - required alignment of starting offset, may be 0 but > > + * if specified, this must be a power-of-two and at least > > + * #I915_GTT_MIN_ALIGNMENT > > + * @color - color to apply to node > > + * @start - start of any range restriction inside GTT (0 for all), > > + * must be #I915_GTT_PAGE_SIZE aligned > > + * @end - end of any range restriction inside GTT (U64_MAX for all), > > + * must be #I915_GTT_PAGE_SIZE aligned > > + * @flags - control search and eviction behaviour > > + * > > + * i915_gem_gtt_insert() first searches for an available hole into which > > + * is can insert the node. The hole address is aligned to @alignment and > > + * its @size must then fit entirely within the [@start, @end] bounds. The > > + * nodes on either side of the hole must match @color, or else a guard page > > + * will be inserted between the two nodes (or the node evicted). If no > > + * suitable hole is found, then the LRU list of objects within the GTT > > + * is scanned to find the first set of replacement nodes to create the hole. > > + * Those old overlapping nodes are evicted from the GTT (and so must be > > + * rebound before any future use). Any node that is current pinned cannot > > "currently" > > > + * be evicted (see i915_vma_pin()). Similar if the node's VMA is currently > > + * active and #PIN_NONBLOCK is specified, that node is also skipped when > > + * searching for an eviction candidate. See i915_gem_evict_something() for > > + * the gory details on the eviction algorithm. > > + * > > + * Returns: 0 on success, -ENOSPC if no suitable hole is found, -EINTR if > > + * asked to wait for eviction and interrupted. > > + */ > > Fit those fixed, good to merge. Thanks for proof reading. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
