Hi,
It might also be worth testing the impact of IOMMU L1 on GTT throughput.
Set IOMMU_L2INDX:L2_DEBUG_3 bit 31 (at any time) to disable the L1.
On 2016-04-14 06:28, Christian König wrote:
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 <mic...@daenzer.net>
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 <marek.ol...@amd.com>
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
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Jay Cornwall
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
