On 07/10/2016 10:46, Chris Wilson wrote:
A while ago we switched from a contiguous array of pages into an sglist,
for that was both more convenient for mapping to hardware and avoided
the requirement for a vmalloc array of pages on every object. However,
certain GEM API calls (like pwrite, pread as well as performing
relocations) do desire access to individual struct pages. A quick hack
was to introduce a cache of the last access such that finding the
following page was quick - this works so long as the caller desired
sequential access. Walking backwards, or multiple callers, still hits a
slow linear search for each page. One solution is to store each
successful lookup in a radix tree.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_drv.h | 57 ++++--------
drivers/gpu/drm/i915/i915_gem.c | 149 ++++++++++++++++++++++++++++----
drivers/gpu/drm/i915/i915_gem_stolen.c | 4 +-
drivers/gpu/drm/i915/i915_gem_userptr.c | 4 +-
4 files changed, 154 insertions(+), 60 deletions(-)
Am curious to know if you have any performance data to show how much of
a benefit this is? Are there any real world apps that would notice or
just IGT benchmarks?
Reviewed-by: John Harrison <john.c.harri...@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
