On 30.04.2016 05:26, Michel Dänzer wrote:
On 28.04.2016 10:54, Michel Dänzer wrote:
On 23.04.2016 07:24, Marek Olšák wrote:
On Fri, Apr 22, 2016 at 11:28 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
On 22.04.2016 12:29, Nicolai Hähnle wrote:
On 20.04.2016 23:02, Michel Dänzer wrote:
On 21.04.2016 02:42, Marek Olšák wrote:
On Thu, Apr 14, 2016 at 9:29 AM, Michel Dänzer <mic...@daenzer.net>
wrote:
Also, with the code modified to use GTT only for everything but
(potential) scanout buffers, the performance of Unigine Valley and the
Unreal Engine 4 Elemental demo is reduced by about 30%. So the premise
that GTT is about as fast as VRAM doesn't seem to hold true in practice
(at least with Kaveri and presumably other (pre-)CIK APUs; maybe it's
better with Carrizo and newer), which means that this change may cause
performance of long-running processes to drop significantly over time.
Given all these issues, I'm afraid it may be better to revert this
change for now, until we have a better plan for dealing with this.
Assuming you use the radeon kernel driver and you are not busy, would
you please check whether the performance is lower on amdgpu as well?
I am using the radeon driver, but also quite busy. Nicolai, can you try
it on your Carrizo?
I don't see any difference on Unigine Valley with my Carrizo (512MB of
VRAM).
I have learned an important lesson today: the Phoronix Test Suite runner
eats my environment variables (and possibly babies?). So my earlier tests
were for nothing.
In reality, Unigine Valley gains about 30% frame rate with the VRAM_GTT
placement.
It looks like we do need Kaveri results on amdgpu to know if CIK or
radeon is the issue. Then, we can either turn it off for radeon or
CIK.
Actually, it sounds like Nicolai may have compared different things than
I did. I compared the current code (using VRAM_GTT) with the patch
below, which uses GTT only for everything but (potential) scanout
buffers. The idea being to measure the performance of GTT vs VRAM
(assuming that most BOs end up in VRAM with VRAM_GTT), with GTT
representing the long term performance of long running apps, because
BOs will get evicted from VRAM to GTT and never moved back to VRAM
after that.
This patch decreased performance by about 30% on my Kaveri with the
radeon driver. I'll compare with amdgpu as well when I get a chance, but
it might be a while, so anybody feel free to beat me to it.
With the patch that sets GTT on (almost) everything, performance is
indeed about 10%-15% lower on average. That's at least the same
direction as what you've observed.
I've now measured the same difference with Unigine Valley on amdgpu on
Kaveri.
Nicolai, when you're measuring this on Carrizo, please make sure the
workload fits into VRAM, to avoid artificially lowering the VRAM numbers.
Well, the BIOS won't let me select more than 512MB VRAM, and some scenes
of Unigine Valley go above that even in Low settings. In any case, it's
clear that VRAM_GTT is better than GTT (and better than VRAM).
Nicolai
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev