[Intel-gfx] Fencing on the i915

Jesse Barnes jbarnes at virtuousgeek.org
Mon Feb 9 20:06:57 CET 2009

On Monday, February 9, 2009 4:11 am Chris Wilson wrote:
> And finally, the changes for the most obvious issues with fencing and my
> i915.
> Please review, thanks.

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b0b1e17..557b7ba 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1572,6 +1572,7 @@ i915_gem_object_get_fence_reg(struct drm_gem_object 
*obj, bool write)
        i915_verify_fence (dev, __FILE__, __LINE__);
        /* First try to find a free reg */
        for (i = dev_priv->fence_reg_start; i < dev_priv->num_fence_regs; i++) 
                reg = &dev_priv->fence_regs[i];
@@ -1584,7 +1585,6 @@ i915_gem_object_get_fence_reg(struct drm_gem_object 
*obj, bool write)
                struct drm_i915_gem_object *old_obj_priv = NULL;
                loff_t offset;
                /* Could try to use LRU here instead... */
                for (i = dev_priv->fence_reg_start;
                     i < dev_priv->num_fence_regs; i++) {

We could use an object existence check in the inner loop instead right?  
Either way this section probably wants some more comments (maybe you do that 
in a later patch though).


Yeah, this is a clear fix.  We should be doing fence allocation even if the 
object already has GTT space.


Hm, this is ugly (not your code, the problem itself).  So if userspace has 
pinned some buffers, we may mistakenly think that a given execbuf has enough 
fence regs to complete its rendering.  Detecting that case is definitely a 
good thing, but we also need to avoid it...  so I guess check_aperture may 
need an update?


Should probably comment what's going on here...  Looks like we're waiting for 
the first non-active object's seqno?


Seems reasonable; I don't think removing the fence register will do anything 
special, so waiting for the rendering to finish seems like a good idea.

Thanks for all this; having non-X clients should really help make this code 
more robust.


More information about the Intel-gfx mailing list