> -----Original Message----- > From: Intel-gfx [mailto:[email protected]] On Behalf > Of Chris Wilson > Sent: Wednesday, January 14, 2015 11:21 AM > To: [email protected] > 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 <[email protected]> > ---
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 <[email protected]> _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
