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. Best regards Akash _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
