GPU relocs are gone. There should be no need for this workaround anymore. Remove it.
Signed-off-by: Thomas Hellström thomas.hellstrom@linux.intel.com --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 19 +------------------ 1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 1231224728e4..04af88e6d453 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -1327,7 +1327,6 @@ eb_relocate_entry(struct i915_execbuffer *eb, { struct drm_i915_private *i915 = eb->i915; struct eb_vma *target; - int err;
/* we've already hold a reference to all valid objects */ target = eb_get_vma(eb, reloc->target_handle); @@ -1357,25 +1356,9 @@ eb_relocate_entry(struct i915_execbuffer *eb, return -EINVAL; }
- if (reloc->write_domain) { + if (reloc->write_domain) target->flags |= EXEC_OBJECT_WRITE;
- /* - * Sandybridge PPGTT errata: We need a global gtt mapping - * for MI and pipe_control writes because the gpu doesn't - * properly redirect them through the ppgtt for non_secure - * batchbuffers. - */ - if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION && - GRAPHICS_VER(eb->i915) == 6) { - err = i915_vma_bind(target->vma, - target->vma->obj->cache_level, - PIN_GLOBAL, NULL); - if (err) - return err; - } - } - /* * If the relocation already has the right value in it, no * more work needs to be done.
On Wed, 27 Oct 2021 at 09:36, Thomas Hellström thomas.hellstrom@linux.intel.com wrote:
GPU relocs are gone. There should be no need for this workaround anymore. Remove it.
Signed-off-by: Thomas Hellström thomas.hellstrom@linux.intel.com
I was completely wrong here, sorry. Digging through the git history it looks like this came from:
Commit 149c84077fe717af883bae459623ef1cebd86388 Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Wed Feb 15 23:50:23 2012 +0100
drm/i915: implement SNB workaround for lazy global gtt
PIPE_CONTROL on snb needs global gtt mappings in place to workaround a hw gotcha. No other commands need such a workaround. Luckily we can detect a PIPE_CONTROL commands easily because they have a write_domain = I915_GEM_DOMAIN_INSTRUCTION (and nothing else has that).
so it looks to be unrelated to GPU relocs, which AFAIK didn't exist at the time. I just saw the MI comment and assumed it was talking about the MI_STORE_DWORD...
.../gpu/drm/i915/gem/i915_gem_execbuffer.c | 19 +------------------ 1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 1231224728e4..04af88e6d453 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -1327,7 +1327,6 @@ eb_relocate_entry(struct i915_execbuffer *eb, { struct drm_i915_private *i915 = eb->i915; struct eb_vma *target;
int err; /* we've already hold a reference to all valid objects */ target = eb_get_vma(eb, reloc->target_handle);
@@ -1357,25 +1356,9 @@ eb_relocate_entry(struct i915_execbuffer *eb, return -EINVAL; }
if (reloc->write_domain) {
if (reloc->write_domain) target->flags |= EXEC_OBJECT_WRITE;
/*
* Sandybridge PPGTT errata: We need a global gtt mapping
* for MI and pipe_control writes because the gpu doesn't
* properly redirect them through the ppgtt for non_secure
* batchbuffers.
*/
if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION &&
GRAPHICS_VER(eb->i915) == 6) {
err = i915_vma_bind(target->vma,
target->vma->obj->cache_level,
PIN_GLOBAL, NULL);
if (err)
return err;
}
}
/* * If the relocation already has the right value in it, no * more work needs to be done.
-- 2.31.1
dri-devel@lists.freedesktop.org