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