On Tue, Dec 20, 2016 at 02:14:21PM +0000, Tvrtko Ursulin wrote: > > 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! :) I know, I'm thinking ahead of documenting the types around the place so that we can start actually preparing for huge objects. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
