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

[Christian König]

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