On 05/11/15 12:58, Chris Wilson wrote:
On Thu, Nov 05, 2015 at 12:53:20PM +0000, Tvrtko Ursulin wrote:
On 05/11/15 12:42, Chris Wilson wrote:
On Thu, Nov 05, 2015 at 12:37:46PM +0000, Tvrtko Ursulin wrote:
On 05/11/15 11:45, ankitprasad.r.sharma@xxxxxxxxx wrote:
From: Ankitprasad Sharma <ankitprasad.r.sharma@xxxxxxxxx>
In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
we try a nonblocking pin for the whole object (since that is fastest if
reused), then failing that we try to grab one page in the mappable
aperture. It also allows us to handle objects larger than the mappable
aperture (e.g. if we need to pwrite with vGPU restricting the aperture
to a measely 8MiB or something like that).
Aperture in aperture, reminds me of those "Yo dawg I've heard you
like X so I've put X in your X so you can Y while you Y" jokes. :D
Would using the partial view code be interesting for this? Might be
faster due to larger chunks possible, or slower due more expensive
set up time, I don't know.
It's the wrong abstraction.
Looks the same to me, only difference is the size.
There are many places that insert-page is used where we cannot do a
partial-pin.
Why not just to the page aperture then for simplicity? If there is
any performance gain from trying the full VMA first then why there
wouldn't be some to try with the partial VMA?
obj->base.size >> PAGE_SHIFT x partial pages is not even funny.
Well I did not suggest that but larger chunks so I will repeat my question.
If going page by page is fine for performance then why have the two code
paths at all? One which tries top pin the whole object first, and second
which goes page by page if that fails. Why not just do it page by page
and avoid having two copy loops etc?
On the other hand, if there is significant performance hit with the page
by page path, then why not use partial views with 1Mb chunks or something?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
