Message ID | 1305235044-9159-11-git-send-email-chris@chris-wilson.co.uk (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Thu, 12 May 2011 22:17:18 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote: > As we cannot wait upon an object to be released by the GPU once we have > disabled pagefaults, process any pending retirements first in the hope > that we move any potential relocations off the active list. This seems to indicate a problem in user space. In any hot-path code, user space should already have correctly computed the relocation values and so the kernel should not have to map and re-write the value. Kernel relocations are a requirement of the architecture, but not something we should hit in practice once the application has gotten itself running in a steady state.
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 20a4cc5..3c639ba 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -446,6 +446,12 @@ i915_gem_execbuffer_relocate(struct drm_device *dev, struct drm_i915_gem_object *obj; int ret = 0; + /* Try to move as many of the relocation targets off the active list + * to avoid unnecessary fallbacks to the slow path, as we cannot wait + * for the retirement with pagefaults disabled. + */ + i915_gem_retire_requests(dev); + /* This is the fast path and we cannot handle a pagefault whilst * holding the struct mutex lest the user pass in the relocations * contained within a mmaped bo. For in such a case we, the page