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

[Akash Goel]

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.

Best regards
Akash