| Message ID | 1302697540-27324-1-git-send-email-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, 13 Apr 2011 13:25:40 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote: > This is vital to maintain our contract with the hw for not using fences > on snooped memory for older chipsets. It should have no impact > other than clearing the fence register (and updating the fence > bookkeeping) as any future IO access (page faults or pwrite/pread) will > go through the cached CPU domain for older chipsets. On SandyBridge, we > incur an extra get_fence() on the rare path that we need to perform > detiling through a pagefault (i.e. texture transfers). Surely you could just update this to do that for the hardware that requires it. With a comment so someone doesn't delete it later :) > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > --- > drivers/gpu/drm/i915/i915_gem.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 6ca026d..2d16a23 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3355,6 +3355,10 @@ int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj, > if (ret) > return ret; > > + ret = i915_gem_object_put_fence(obj); > + if (ret) > + return ret; > + > ret = i915_gem_gtt_bind_object(obj, cache_level); > if (ret) > return ret; > -- > 1.7.4.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, 13 Apr 2011 09:36:08 -0700, Eric Anholt <eric@anholt.net> wrote: > On Wed, 13 Apr 2011 13:25:40 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote: > > This is vital to maintain our contract with the hw for not using fences > > on snooped memory for older chipsets. It should have no impact > > other than clearing the fence register (and updating the fence > > bookkeeping) as any future IO access (page faults or pwrite/pread) will > > go through the cached CPU domain for older chipsets. On SandyBridge, we > > incur an extra get_fence() on the rare path that we need to perform > > detiling through a pagefault (i.e. texture transfers). > > Surely you could just update this to do that for the hardware that > requires it. With a comment so someone doesn't delete it later :) The comment is surely lacking, yes. But the test here for the right generations is just ugly since losing a CPU fence register is not that big an issue -- the largest overhead will be in reinstating the vma, and we need to do that anyway if we mix CPU / GTT reads through the pagefault handler. -Chris
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 6ca026d..2d16a23 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3355,6 +3355,10 @@ int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj, if (ret) return ret; + ret = i915_gem_object_put_fence(obj); + if (ret) + return ret; + ret = i915_gem_gtt_bind_object(obj, cache_level); if (ret) return ret;
This is vital to maintain our contract with the hw for not using fences on snooped memory for older chipsets. It should have no impact other than clearing the fence register (and updating the fence bookkeeping) as any future IO access (page faults or pwrite/pread) will go through the cached CPU domain for older chipsets. On SandyBridge, we incur an extra get_fence() on the rare path that we need to perform detiling through a pagefault (i.e. texture transfers). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_gem.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)