| Message ID | 1302717671-1914-1-git-send-email-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Apr 13, 2011 at 07:01:11PM +0100, Chris Wilson 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 > be linear and go through the cached CPU domain. set_cache_level is rather unused on pre-snb. Can't we just hold off with such complexity before we actually use it in e.g. the vmap code? Maybe add a WARN_ON(gen < 6) instead? -Daniel
On Wed, 13 Apr 2011 22:46:47 +0200, Daniel Vetter <daniel@ffwll.ch> wrote: > set_cache_level is rather unused on pre-snb. Can't we just hold off with > such complexity before we actually use it in e.g. the vmap code? Maybe add > a WARN_ON(gen < 6) instead? You might argue that set_cache_level is not used even on SNB at the point at which we are writing the interface for it... Once you've finished reviewing this code, I have another batch... ;-) -Chris
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index c38b011..39c50eb 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3358,6 +3358,16 @@ int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj, if (ret) return ret; + /* Before SandyBridge, you could not use tiling or fence + * registers with snooped memory, so relinquish any fences + * currently pointing to our region in the aperture. + */ + if (INTEL_INFO(obj->base.dev)->gen < 6) { + 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 be linear and go through the cached CPU domain. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_gem.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-)