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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx wrote:
> > > From: Akash Goel <akash.goel@xxxxxxxxx>
> > > 
> > > 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. "Kept enabled" so you have a buffer
already allocated?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux