From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction Date: Thu, 29 Nov 2012 09:04:36 +0100 Message-ID: <50B71714.4060802@shipmail.org> References: <1354118328-8104-1-git-send-email-j.glisse@gmail.com> <1354118328-8104-2-git-send-email-j.glisse@gmail.com> <50B69BB2.5040908@shipmail.org> <1354146298.13769.12.camel@trillian.infiniteimprobability.net> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from GOTHNET-SMTP2.gothnet.se (ns2.gothnet.se [82.193.160.251]) by gabe.freedesktop.org (Postfix) with ESMTP id 20336E5DC2 for ; Thu, 29 Nov 2012 00:04:43 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: =?windows-1252?Q?Marek_Ol=9A=E1k?= Cc: Jerome Glisse , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 11/29/2012 03:15 AM, Marek Ol=9A=E1k wrote: > On Thu, Nov 29, 2012 at 12:44 AM, Alan Swanson wrote: >> On Wed, 2012-11-28 at 18:24 -0500, Jerome Glisse wrote: >>> On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom = wrote: >>>> On 11/28/2012 04:58 PM, j.glisse@gmail.com wrote: >>>>> From: Jerome Glisse >>>>> >>>>> This patch add a minimum residency time configurable for each memory >>>>> pool (VRAM, GTT, ...). Intention is to avoid having a lot of memory >>>>> eviction from VRAM up to a point where the GPU pretty much spend all >>>>> it's time moving things in and out. >>>> >>>> This patch seems odd to me. >>>> >>>> It seems the net effect is to refuse evictions from VRAM and make buff= ers go >>>> somewhere else, and that makes things faster? >>>> >>>> Why don't they go there in the first place instead of trying to force = them >>>> into VRAM, >>>> when VRAM is full? >>>> >>>> /Thomas >>> It's mostly a side effect of cs and validating with each cs, if boA is >>> in cs1 and not in cs2 and boB is in cs1 but not in cs2 than boA could >>> be evicted by cs2 and boB moved in, if next cs ie cs3 is like cs1 then >>> boA move back again and boB is evicted, then you get cs4 which >>> reference boB but not boA, boA get evicted and boB move in ... So ttm >>> just spend its time doing eviction but he doing so because it's ask by >>> the driver to do so. Note that what is costly there is not the bo move >>> in itself but the page allocation. >>> >>> I propose this patch to put a boundary on bo eviction frequency, i >>> thought it might help other driver, if you set the residency time to 0 >>> you get the current behavior, if you don't you enforce a minimum >>> residency time which helps driver like radeon. Of course a proper fix >>> to the bo eviction for radeon has to be in radeon code and is mostly >>> an overhaul of how we validate bo. >>> >>> But i still believe that this patch has value in itself by allowing >>> driver to put a boundary on buffer movement frequency. >>> >>> Cheers, >>> Jerome >> So, a variation on John Carmack's recommendation from 2000 to use MRU, >> not LRU, to avoid texture trashing. >> >> Mar 07, 2000 - Virtualized video card local memory is The Right Thing. >> http://floodyberry.com/carmack/johnc_plan_2000.html >> >> In fact, this was last discussed in 2005 with a patch for a 1 second >> stale texture eviction and I (still) wondered why a method it was never >> implemented since it was an clear problem. > BTW we can send end-of-frame markers to the kernel, which could be > used to implement Carmack's algorithm. > > Marek It seems to me like Carmack's algorithm is quite specific to the case = where only a single GL client is running? It also seems like it's designed around the fact that when eviction = takes place, all buffer objects will be idle. With a reasonably filled graphics fifo / ring, blindly using MRU will cause the = GPU to run synchronized. /Thomas > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel