[Mesa-dev] Mesa (master): 29 new commits

[Jay Cornwall]

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 <michel at 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.olsak at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jay Cornwall