Quoting Chris Wilson (2018-09-11 14:57:46) > If the caller supplies more than 4G of objects and than one that has to > be in the low 4G, it is possible for the low 4G to be full before we > attempt to find room for the last object that must be there. As we don't > reorder the two types, every pass hits the same problem and we fail with > ENOSPC. However, if we impose a little bit of ordering between the two > classes of objects, on the second pass we will be able to fit the > special object as we do it first. For setups that only use !48b objects, > we now reverse the order between passes, hopefully making the subsequent > passes more likely to succeed given that we are trying a different > order (rather than repeating the previous pass!) > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Might be worthy dropping a one-liner comment in the fashion of. /* Avoid congesting 4GB region required for last object. */ Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> Regards, Joonas > --- > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > index 22b4cb775576..d70d142f5338 100644 > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > @@ -696,6 +696,8 @@ static int eb_reserve(struct i915_execbuffer *eb) > list_add(&vma->exec_link, &eb->unbound); > else if (flags & __EXEC_OBJECT_NEEDS_MAP) > list_add_tail(&vma->exec_link, &eb->unbound); > + else if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS)) > + list_add(&vma->exec_link, &last); > else > list_add_tail(&vma->exec_link, &last); > } > -- > 2.19.0.rc2 > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
