[Intel-gfx] [RFC] drm/i915: Scratch page optimization for blanking buffer

Akash Goel akash.goel at intel.com
Mon May 5 14:53:52 CEST 2014


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 at intel.com wrote:
> > > > From: Akash Goel <akash.goel at 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




More information about the Intel-gfx mailing list