[PATCH] drm/i915: Remove bogus test for a present execbuffer

[PATCH] drm/i915: Remove bogus test for a present execbuffer

[Chris Wilson]

The intention of checking obj->gtt_offset!=0 is to verify that the
target object was listed in the execbuffer and had been bound into the
GTT. This is guarranteed by the earlier rearrangement to split the
execbuffer operation into reserve and relocation phases and then
verified by the check that the target handle had been processed during
the reservation phase.

However, the actual checking of obj->gtt_offset==0 is bogus as we can
indeed reference an object at offset 0. For instance, the framebuffer
installed by the BIOS often resides at offset 0 - causing EINVAL as we
legimately try to render using the stolen fb.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |    9 ---------
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index ec22c1d..7a6f6fc 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -204,15 +204,6 @@ i915_gem_execbuffer_relocate_entry(struct drm_i915_gem_object *obj,
 					 target_i915_obj->cache_level);
 	}
 
-	/* The target buffer should have appeared before us in the
-	 * exec_object list, so it should have a GTT space bound by now.
-	 */
-	if (unlikely(target_offset == 0)) {
-		DRM_DEBUG("No GTT space found for object %d\n",
-			  reloc->target_handle);
-		return ret;
-	}
-
 	/* Validate that the target is in a valid r/w GPU domain */
 	if (unlikely(reloc->write_domain & (reloc->write_domain - 1))) {
 		DRM_DEBUG("reloc with multiple write domains: "
-- 
1.7.10.4

Re: [PATCH] drm/i915: Remove bogus test for a present execbuffer

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 828 bytes --]

Chris Wilson <chris@chris-wilson.co.uk> writes:

> The intention of checking obj->gtt_offset!=0 is to verify that the
> target object was listed in the execbuffer and had been bound into the
> GTT. This is guarranteed by the earlier rearrangement to split the
> execbuffer operation into reserve and relocation phases and then
> verified by the check that the target handle had been processed during
> the reservation phase.
>
> However, the actual checking of obj->gtt_offset==0 is bogus as we can
> indeed reference an object at offset 0. For instance, the framebuffer
> installed by the BIOS often resides at offset 0 - causing EINVAL as we
> legimately try to render using the stolen fb.

We've never triggered this check in practice, as far as I know, so I'm
happy to see it go.

Reviewed-by: Eric Anholt <eric@anholt.net>

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Remove bogus test for a present execbuffer

[Daniel Vetter]

On Mon, Nov 19, 2012 at 08:42:59AM -0800, Eric Anholt wrote:
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> 
> > The intention of checking obj->gtt_offset!=0 is to verify that the
> > target object was listed in the execbuffer and had been bound into the
> > GTT. This is guarranteed by the earlier rearrangement to split the
> > execbuffer operation into reserve and relocation phases and then
> > verified by the check that the target handle had been processed during
> > the reservation phase.
> >
> > However, the actual checking of obj->gtt_offset==0 is bogus as we can
> > indeed reference an object at offset 0. For instance, the framebuffer
> > installed by the BIOS often resides at offset 0 - causing EINVAL as we
> > legimately try to render using the stolen fb.
> 
> We've never triggered this check in practice, as far as I know, so I'm
> happy to see it go.
> 
> Reviewed-by: Eric Anholt <eric@anholt.net>

Queued for -next, thanks for the patch.
-Daniel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch