[PATCH] Move the fence register allocation for pin on !965G to outside the if (!bound) check.

Owain G. Ainsworth oga at openbsd.org
Thu Feb 26 10:19:03 PST 2009


The reason for this is that when the gtt mapping code needs a fence
register, it will wait for a buffer to idle, leave it bound, and steal
the register. So if our buffer to be pinned was bound, and gtt mapping
had taken its fence register, it would go into execbuffer unfenced.

Found by code inspection.

Signed-Off-By: Owain G. Ainsworth <oga at openbsd.org>
---
 drivers/gpu/drm/i915/i915_gem.c |   18 ++++++++++--------
 1 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 026c0ef..6739ca5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2721,15 +2721,17 @@ i915_gem_object_pin(struct drm_gem_object *obj, uint32_t alignment)
 				DRM_ERROR("Failure to bind: %d", ret);
 			return ret;
 		}
-		/*
-		 * Pre-965 chips need a fence register set up in order to
-		 * properly handle tiled surfaces.
-		 */
-		if (!IS_I965G(dev) &&
-		    obj_priv->fence_reg == I915_FENCE_REG_NONE &&
-		    obj_priv->tiling_mode != I915_TILING_NONE)
-			i915_gem_object_get_fence_reg(obj, true);
 	}
+	/*
+	 * Pre-965 chips need a fence register set up in order to
+	 * properly handle tiled surfaces.
+	 * Do this here in case gtt mapping stole our reg.
+	 */
+	if (!IS_I965G(dev) &&
+	    obj_priv->fence_reg == I915_FENCE_REG_NONE &&
+	    obj_priv->tiling_mode != I915_TILING_NONE)
+		i915_gem_object_get_fence_reg(obj, true);
+
 	obj_priv->pin_count++;
 
 	/* If the object is not active and not pending a flush,
-- 
1.6.0.5


More information about the Intel-gfx mailing list