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

[Daniel Vetter]

On Wed, May 07, 2014 at 11:19:57AM +0530, Akash Goel wrote:
> On Mon, 2014-05-05 at 16:07 +0200, Daniel Vetter 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.
> > > 
> > > Signed-off-by: Akash Goel <akash.goel at intel.com>
> > 
> > That sounds very much like a special case of the fallocate ioctl where we
> > simply allocat 0 real backing storage pages.
> > -Daniel
> > 
> 
> Hi Daniel,
> 
> Yes no real backing storage is needed, but still the object should be
> allowed to get mapped into the GGTT, using the scratch page (already
> zeroed out).
> 
> Is there a patch for a new drm/i915 ioctl similar to fallocate, which
> could be used here?

Geez, you guys shouldn't just dump patches onto intel-gfx but read a bit
what other people are doing. Especially when they work for the same team
;-)

http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/36351

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch