Quoting Matthew Auld (2020-12-24 14:34:55) > The reloc batch is short lived but can exist in the user visible ppGTT, > and since it's backed by an internal object, which lacks page clearing, > we should take care to clear it upfront. > > Signed-off-by: Matthew Auld <matthew.auld@xxxxxxxxx> > --- > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c > index 0cf9e79325a8..a4ecd4b4e874 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c > @@ -1295,6 +1295,9 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb, > goto err_pool; > } > > + memset64((void*)cmd, 0, pool->obj->base.size / sizeof(u64)); Might as well make it memset32 to avoid the cast. I'm willing to bet it's in the noise by that point on 4096+ object. > + i915_gem_object_flush_map(pool->obj); We really don't want to have to flush it twice. Remove the limit on the flush_map before submission. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
