[Intel-gfx] [PATCH 2/5] drm/i915: Fallback to using CPU relocations for large batch buffers

[Daniel, Thomas]

> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf
> Of Chris Wilson
> Sent: Wednesday, January 14, 2015 11:21 AM
> To: intel-gfx at lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/5] 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 at chris-wilson.co.uk>
> ---

I was asked to look at the original version of this patch, so I did.  And I looked at this too.
All looks sensible.

Reviewed-by: Thomas Daniel <thomas.daniel at intel.com>