Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754608Ab1C3Hcj (ORCPT ); Wed, 30 Mar 2011 03:32:39 -0400 Received: from mga14.intel.com ([143.182.124.37]:41633 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753672Ab1C3Hci (ORCPT ); Wed, 30 Mar 2011 03:32:38 -0400 Message-Id: <849307$c7qtj5@azsmga001.ch.intel.com> X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.63,267,1299484800"; d="scan'208";a="410875493" Date: Wed, 30 Mar 2011 08:32:33 +0100 To: Dave Airlie , Jerome Glisse Subject: Re: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown() Cc: r6144 , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org References: <1301310995.5615.92.camel@wangqingchuan> <1301336010.2217.20.camel@workstation> <1301409864.5615.98.camel@wangqingchuan> <1301421664.2151.12.camel@Portable-Work> <20110329202608.GA3454@viiv.ffwll.ch> From: Chris Wilson In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1558 Lines: 32 On Wed, 30 Mar 2011 07:57:49 +1000, Dave Airlie wrote: > On Wed, Mar 30, 2011 at 7:04 AM, Jerome Glisse wrote: > > What i had in mind was something little bit more advance that pwrite, > > somethings that would take width,height,pitch of userpage and would be > > able to perform proper blit. But yes pwrite in intel is kind of > > limited. > > TTM has support for userpage binding we just don't use it. Yes, and I've been experimenting with the same in GEM to great effect in the DDX. The complication remains in managing the CPU synchronisation, which suggests that it would only be useful for STREAM_DRAW objects (and perhaps the sub-region updates to STATIC_DRAW). (And for readback, if retrieving the data were the actual bottleneck.) And I did play with a new pread/pwrite interface that did as you suggest, binding the user pages and performing a blit. But by the time you make the interface asynchronous, it becomes much easier to let the client code create the mapping and be fully aware of the barriers. And yes I do concur that vma bookkeeping does impose significant overheads and I have been removing as many mappings from our drivers as I can; within the limitations of the pwrite interface. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/