| Message ID | 20180911115810.8917-2-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [01/26] drm/i915/ringbuffer: Reload PDs harder on byt/bcs | expand |
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@chris-wilson.co.uk> 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@linux.intel.com> 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 >
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); }
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@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 ++ 1 file changed, 2 insertions(+)