Re: [RFC] drm/i915: Scratch page optimization for blanking buffer

[Akash Goel <akash.goel@intel.com>]

On Mon, 2014-05-05 at 13:39 +0100, Chris Wilson wrote:
> On Mon, May 05, 2014 at 06:03:17PM +0530, Akash Goel wrote:
> > On Mon, 2014-05-05 at 12:47 +0100, Chris Wilson wrote:
> > > On Mon, May 05, 2014 at 05:13:18PM +0530, akash.goel@intel.com wrote:
> > > > From: Akash Goel <akash.goel@intel.com>
> > > > 
> > > > There is a use case, when user space (display compositor) tries
> > > > to directly flip a fb (without any prior rendering) on primary
> > > > plane. So the backing pages of the object are allocated at page
> > > > flip time only, which takes time. Since, this buffer is supposed to
> > > > serve as a blanking buffer (black colored), we can setup all the GTT entries
> > > > of that blanking buffer with scratch page (which is already zeroed out).
> > > > This saves the time in allocation of real backing physical space for the
> > > > blanking buffer and flushing of CPU cache.
> > > 
> > > So what happens with concurrent rendering via the GPU or GTT? And who
> > > said that scratch was blank?
> > > 
> > > I wonder if there is a trivial operation in which you could grab the
> > > pages and pull it into the mappable area prior to flipping.
> > > -Chris
> > > 
> > 
> > Actually we are trying to address a special case here.
> > Sometimes the primary plane has to be kept enabled forcefully, even
> > though there is no real update required on it, whereas the actual update
> > is happening on the sprite plane. In that case a fb (coined as a
> > 'blanking' buffer) is allocated on the fly and page-flipped on primary
> > plane. So the case of concurrent rendering is not applicable here
> > 
> > As the blanking buffer is supposed to be black colored and shmem
> > allocated buffer is by default zeroed out, so this buffer is flipped
> > directly.
> > 
> > Since in driver we already allocate a scratch page(already zeroed out),
> > which is mapped by all unused GTT entries, we can use this scratch page
> > itself as a backing store for the blanking buffer, instead of allocating
> > real pages for it from shmem.
> 
> However, it is a scratch page, not a zero page. You can rely on it
> containing garbage at some point.

Actually the scratch page has been allocated through the alloc_page call
with __GFP_ZERO flag.
	page = alloc_page(GFP_KERNEL | GFP_DMA32 | __GFP_ZERO);
So that's why are banking on scratch page to be zeroed out.

>  "Kept enabled" so you have a buffer already allocated?
> -Chris
> 
Yes the primary plane has to be enabled, even though the updates are
happening only on Sprite plane.  
Sorry I am not able to recall the exact use case. I will check with the
Display compositor folks and get back on this.
One reason could be because the 'flip done' notifications are available
only with primary plane. 

Best regards
Akash