Re: [PATCH 01/11] drm/i915: Add support for mapping an object page by page

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux