Re: [PATCH 3/3] drm/i915: Use insert_page for pwrite_fast

From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	ankitprasad.r.sharma@intel.com, intel-gfx@lists.freedesktop.org,
	akash.goel@intel.com
Subject: Re: [PATCH 3/3] drm/i915: Use insert_page for pwrite_fast
Date: Thu, 5 Nov 2015 14:38:30 +0000	[thread overview]
Message-ID: <563B69E6.9030605@linux.intel.com> (raw)
In-Reply-To: <20151105125814.GD669@nuc-i3427.alporthouse.com>

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@intel.com wrote:
>>>>> From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
>>>>>
>>>>> 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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx