drm/i915: Fallback to using CPU relocations for large batch buffers
authorChris Wilson <chris@chris-wilson.co.uk>
Wed, 14 Jan 2015 11:20:56 +0000 (11:20 +0000)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Fri, 20 Mar 2015 10:48:13 +0000 (11:48 +0100)
commitedf4427b8055dc93eb5222d8174b07a75ba24fb5
tree3cf0e04fde87d9063731273b56f60f31c1553661
parent6fafab76d5189312bf45e71254b5aba5faf7a31b
drm/i915: Fallback to using CPU relocations for large batch buffers

If the batch buffer is too large to fit into the aperture and we need a
GTT mapping for relocations, we currently fail. This only applies to a
subset of machines for a subset of environments, quite undesirable. We
can simply check after failing to insert the batch into the GTT as to
whether we only need a mappable binding for relocation and, if so, we can
revert to using a non-mappable binding and an alternate relocation
method. However, using relocate_entry_cpu() is excruciatingly slow for
large buffers on non-LLC as the entire buffer requires clflushing before
and after the relocation handling. Alternatively, we can implement a
third relocation method that only clflushes around the relocation entry.
This is still slower than updating through the GTT, so we prefer using
the GTT where possible, but is orders of magnitude faster as we
typically do not have to then clflush the entire buffer.

An alternative idea of using a temporary WC mapping of the backing store
is promising (it should be faster than using the GTT itself), but
requires fairly extensive arch/x86 support - along the lines of
kmap_atomic_prof_pfn() (which is not universally implemented even for
x86).

Testcase: igt/gem_exec_big #pnv,byt
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88392
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add a WARN_ONCE for the impossible reloc case and explain in
a short comment why we want to avoid ping-pong.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/gpu/drm/i915/i915_gem_execbuffer.c