drm/i915: Use a radixtree for random access to the object's backing storage

Browse source

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.

v2: Rewrite building the radixtree for clarity, hopefully.

v3: Rearrange execbuf to avoid calling i915_gem_object_get_sg() from
within an atomic section and so relax the allocation context to a simple
GFP_KERNEL and mutex.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-10-chris@chris-wilson.co.uk

...

This commit is contained in:

Chris Wilson 2016-10-28 13:58:33 +01:00

parent 4c7d62c6b8

commit 96d7763452

4 changed files with 199 additions and 63 deletions

Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL

Download patch file Download diff file Expand all files Collapse all files

69

drivers/gpu/drm/i915/i915_drv.h

View file

185

drivers/gpu/drm/i915/i915_gem.c

View file

4

drivers/gpu/drm/i915/i915_gem_stolen.c

View file

4

drivers/gpu/drm/i915/i915_gem_userptr.c

View file