Yeah, thinking about this since I've seen Michels response this morning.
The only major thing which is different is the TLB pressure, e.g. VRAM
is allocated continuously and so you can work much more with setting the
fragmentation flag in the VM page tables.
If you have a system to test this try to disable adding the
fragmentation information to the page table entries in
amdgpu_vm_frag_ptes().
Regards,
Christian.
Am 14.04.2016 um 12:26 schrieb Marek Olšák:
Alex, Christian,
Any idea why GTT is 30% slower on Kaveri than VRAM? See below.
On Thu, Apr 14, 2016 at 9:29 AM, Michel Dänzer <[email protected]> wrote:
On 14.04.2016 11:37, Michel Dänzer wrote:
On 12.04.2016 21:33, Marek =?UNKNOWN?B?T2zFocOhaw==?= wrote:
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=5a4b74d1ba2c156766a7a5dbfef099c7db5d6694
Author: Marek Olšák <[email protected]>
Date: Mon Apr 11 19:56:07 2016 +0200
gallium/radeon: relax requirements on VRAM placements on APUs
This change caused a bunch of ARB_shader_load_image_store piglit tests
to fail on my Kaveri, see some examples below. The incorrect values
seem consistent.
I suppose some buffers end up in GTT instead of VRAM with this
change, but I'm not sure how that could cause problems. Any ideas?
Not at all. We seem to have a coherency or synchronization issue
somewhere. You can also try adding PS_PARTIAL_FLUSH after every draw.
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.
OK.
Marek
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
