From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: [RFC 0/3] TTM priority queue logic Date: Fri, 04 Apr 2014 16:44:32 +0200 Message-ID: <533EC550.9040208@vmware.com> References: <20140404165224.a4856af5.cand@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by gabe.freedesktop.org (Postfix) with ESMTP id EB5C66EDA4 for ; Fri, 4 Apr 2014 07:44:34 -0700 (PDT) In-Reply-To: <20140404165224.a4856af5.cand@gmx.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Lauri Kasanen Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 04/04/2014 03:52 PM, Lauri Kasanen wrote: > Hi list, Thomas, > > I'd like to know if this is going in the right direction. > > I've implemented a priority queue on top of the kernel rb tree and > linked list. It's been tested well in userspace. > > I hardcoded radeon to input the buffer size as the score. Nothing blew > up, games ran fine, and even got ~2% more fps on average*. > > The only thing missing from this code is the "if score is too low, and > there is no room without eviction, tell driver so" logic. > > - Lauri > > * This is a fairly bad strategy, and according to my simulator achieves > 16% worse results compared to LRU in heavier situations. The games > tested here all fit in VRAM, which should explain the improvement Lauri, I'm out of the office until monday, I'll take a look then. Thanks, Thomas