From: Daniel Vetter Subject: Re: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown() Date: Tue, 29 Mar 2011 22:26:08 +0200 Message-ID: <20110329202608.GA3454@viiv.ffwll.ch> References: <1301310995.5615.92.camel@wangqingchuan> <1301336010.2217.20.camel@workstation> <1301409864.5615.98.camel@wangqingchuan> <1301421664.2151.12.camel@Portable-Work> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Jerome Glisse Cc: Lucas Stach , r6144 , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Tue, Mar 29, 2011 at 03:45:34PM -0400, Jerome Glisse wrote: > Short lived & small bo would definitly doesn't work well for this kind > of API, it would all be a function of the ioctl cost. But i am not > sure the drawback would be that big, intel tested with pread/pwrite > and gived up don't remember why. For the vbo case you describe the > scheme i was thinking would be : allocate bo and on buffer data call > upload to the allocated bo using the bind user page feature that would > mean zero extra copy operation. For the fire forget case of vbo, > likely somekind of transient buffer would be more appropriate. Just to clarify: Uploads to linear buffers are all done with pwrite (due to an api foobar, it's not so great for 2d/tiled stuff). It's amazing how much faster that is: Switching vbo's from mmpa to pwrite has given a few percent more fps in openarena in i915g! As long as the chunk you're gonna write fits into L1 cache, it's probably a net win. -Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48