From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC] drm/i915: Scratch page optimization for blanking buffer Date: Wed, 7 May 2014 09:39:10 +0200 Message-ID: <20140507073910.GK5730@phenom.ffwll.local> References: <1399290198-4283-1-git-send-email-akash.goel@intel.com> <20140505140721.GM20800@phenom.ffwll.local> <1399441797.12368.6.camel@akashgoe-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by gabe.freedesktop.org (Postfix) with ESMTP id 426BF6E4A1 for ; Wed, 7 May 2014 00:39:15 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id b57so397051eek.27 for ; Wed, 07 May 2014 00:39:14 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1399441797.12368.6.camel@akashgoe-desktop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Akash Goel Cc: intel-gfx@lists.freedesktop.org, sourab.gupta@intel.com List-Id: intel-gfx@lists.freedesktop.org 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@intel.com wrote: > > > From: Akash Goel > > > > > > 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 > > > > 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