On 15/01/16 11:44, Chris Wilson wrote:
On Fri, Jan 15, 2016 at 09:53:46AM +0000, Tvrtko Ursulin wrote:
On 14/01/16 13:34, Chris Wilson wrote:
On Thu, Jan 14, 2016 at 10:32:11AM +0000, Tvrtko Ursulin wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
index b448ad8..5f86596 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -317,6 +317,11 @@ struct i915_address_space {
uint64_t start,
uint64_t length,
bool use_scratch);
+ void (*insert_page)(struct i915_address_space *vm,
+ dma_addr_t addr,
+ uint64_t offset,
+ enum i915_cache_level cache_level,
+ u32 flags);
void (*insert_entries)(struct i915_address_space *vm,
struct sg_table *st,
uint64_t start,
Why not extend the current API to support start page offset and
number of pages? Could default to full object like today if zero.
Eg:
void (*insert_entries)(struct i915_address_space *vm,
struct sg_table *st,
+ unsigned page_offset,
+ unsigned num_pages,
Ouch. That would be quite slow for the insert_page() use case of
page-by-page looping.
It could use the same last page caching trick so why would be be so slow?
We don't have the convenient struct? I presumed you were thinking of
passing the offset through to sg_page_iter
for_each_sg_page(st->sgl, &sg_iter, st->nents, page_offset) {
if (--num_pages)
break;
/* original pt insertion code */
}
Is it worth expanding struct sg_table for this shortcut?
There are some games where we spend more time in sg_page_iter_next() than
anything else in the kernel. The games have more textures than GTT
space, they aren't playable right now nor will they ever likely to be. :(
Improving these loops would definitely be a boon nevertheless.
Okay, dead end, mission abort. :)
Ankit please just sync the patch in next respin with the RPM changes
which happened in the meantime.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
