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. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
