On 20/12/2016 13:56, Chris Wilson wrote:
On Tue, Dec 20, 2016 at 01:38:16PM +0000, Tvrtko Ursulin wrote:
On 20/12/2016 12:36, Chris Wilson wrote:
On Tue, Dec 20, 2016 at 11:33:27AM +0000, Chris Wilson wrote:
On Tue, Dec 20, 2016 at 11:13:43AM +0000, Tvrtko Ursulin wrote:
How much is the cost of freeing and re-acquiring pages in the fall
back case? It could be avoidable by using the table and adding
something like sgt = i915_sg_copy(sgt, table_max_segment). But it
depends on how likely is this path to be hit on swiotlb platforms. I
have no idea. Our datasets are much bigger than the swiotlb space -
if that is true on such platforms?
It's below my level of care (atm). Platforms hitting this are using
swiotlb *bounce* buffers. They will not be able to support a full gfx
workload and be going through a copy. We could avoid the additional
work, the sg_table is large enough for a 1:1 copy if we do it before the
trim, but more importantly we need a simple fix for 4.10.
Pushed this pair as I think this is the safe course of action. Creating
i915_sg_expand() is a job for a rainy day.
It would have been very simple and much more elegant in my opinion.
I'm ready to be impressed, in my head to do an inplace rewrite was tricky.
:)
Maybe I've missed something then. We'll see. :)
But I understand Tested-by tag was precious to keep. I'll send a
patch shortly but it won't be very tested due to time constraints.
Also I don't know why you changed page_count and i to unsigned long
when the sg API can only handle unsigned int for that.
Primary concern was moving them out of the way and worrying about our
own 64bit object size issues. Hmm, can we reuse
if (overflows_type(pgcount, unsigned int))
return -E2BIG;
to catch the mismatch?
You have already added that to i915_gem_object_create some time ago! :)
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
