From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?windows-1252?Q?Christian_K=F6nig?= Subject: Re: [PATCH 0/6] Radeon memory management improvements Date: Mon, 24 Feb 2014 17:40:49 +0100 Message-ID: <530B7611.3090304@vodafone.de> References: <1393255246-8296-1-git-send-email-maraeo@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38]) by gabe.freedesktop.org (Postfix) with SMTP id A4868FAB4F for ; Mon, 24 Feb 2014 08:41:04 -0800 (PST) In-Reply-To: <1393255246-8296-1-git-send-email-maraeo@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: =?windows-1252?Q?Marek_Ol=9A=E1k?= , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org Hi Marek, Some minor comments on patch 1, 2 and 5, but nothing serious. Patch 3, 4 = and 6 are Reviewed-by: christian K=F6nig See below for a few in line comments. Am 24.02.2014 16:20, schrieb Marek Ol=9A=E1k: > This series improves performance for the cases when there is not enough V= RAM for all buffers. > > First of all, I'd like to mention that if you set both VRAM and GTT domai= ns for a buffer, you pretty much say you don't care where the buffer ends u= p. It usually makes the performance even worse. > > This work was largely benchmark-driven and I tried a lot of ideas before = I found out which ones work. The patches describe what they do and they're = quite simple, so I'll just share the results here. > > > Card: Evergreen Redwood (HD 5670), 512 MB of VRAM > Test: Unigine Heaven 4.0, High settings > > 1) 1280x720, 4x MSAA, need 525 MB of VRAM > > Without patches: 16.6 FPS > With patches: 16.6 FPS > Improvement: 0 % > > 2) 1600x900, 4x MSAA, need 642 MB of VRAM > > Without patches: 7.1 FPS > With patches: 9.7 FPS > Improvement: 36 % > > 3) 1920x1080, 4x MSAA, need 743 MB of VRAM > > Without patches: 3.7 FPS > With patches: 5.6 FPS > Improvement: 51 % > > 4) 1600x900, 8x MSAA, need 838 MB of VRAM > Without patches: 2.9 FPS > With patches: 4.6 FPS > Improvement: 58 % > > These results don't change if you run the benchmark several times, which = proves the improvement is stable. > > > To conclude this, here are ideas for future work: > > 1) Add virtual memory support for VRAM. Our GPUs support virtual memory, = which not only solves fragmentation issues, but it also allows each buffer = to be partially in VRAM and partially in GTT, which becomes more important = with large buffers like 100 MB. Moving whole buffers back and forth between= VRAM and GTT is inefficient if you can do it at page granularity. Also, du= e to fragmentation, we can never really use all of VRAM, but only about 90-= 95%. Yeah, I'm also thinking about this for quite some time now. The basic = problem is that while our GPUs support VM they don't support faulting = pages in and continuing (at least nobody got that working reliable so = far). E.g. when you hit a page fault you can't relocate the page and = then continue. Support for partially resident textures on newer hardware currently = works by splitting the buffer up into smaller buffers in userspace and = then actively checking in the shader if we hit a buffer that's not = currently in memory, but that's not really applicable in the general use = case (to much shader overhead). > 2) Add support for uncached GTT. I think it should improve performance fo= r dGPUs under memory pressure, but some testing needs to be done to confirm= that. Uncached GTT doesn't seem to work for me on Evergreen, but it's said= to be working on some later chips. Did you try to make the whole GTT uncached or just evicted BOs? Making = the whole GTT uncached probably won't work out of the box, but avoiding = setting the "SNOOPED" flag on those pages might get us better = performance while swapping them into VRAM again. Christian. > > The patches for Mesa will follow later today. Please review. > > Marek > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel