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