Re: Plan: BO move throttling for visible VRAM evictions

2017-04-16 Thread Marek Olšák
On Fri, Apr 14, 2017 at 12:14 PM, Michel Dänzer  wrote:
> On 04/04/17 05:11 AM, Marek Olšák wrote:
>> On Fri, Mar 31, 2017 at 5:24 AM, Michel Dänzer  wrote:
>>> On 30/03/17 07:03 PM, Michel Dänzer wrote:
 On 25/03/17 01:33 AM, Marek Olšák wrote:
> Hi,
>
> I'm sharing this idea here, because it's something that has been
> decreasing our performance a lot recently, for example:
> http://openbenchmarking.org/prospect/1703011-RI-RADEONDIR06/7b7668cfc109d1c3dc27e871c8aea71ca13f23fa

 The attached proof-of-concept patch (on top of Christian's "CPU mapping
 of split VRAM buffers" series, ported from radeon) results in 145.05 fps
 on my Tonga.
>>>
>>> I get the same result without my or Christian's patches though, with
>>> 4.11 based DRM or amd-staging-4.9. So I guess I just can't reproduce the
>>> problem with this test. Are there any other tests for it?
>>
>> It's random. Sometimes the benchmark runs OK, other times it's slow.
>> You can easily see the difference but observing how smooth it is. The
>> visible VRAM evictions result in constant 100-200ms stalls but not
>> every frame, which feels like the frame rate is much lower than it
>> actually is.
>>
>> Make sure your graphics details are maxed out. The best score I can
>> get with my rig is 70 fps. (Fiji & Core i5 3570)
>
> I'm getting around 53-54 fps at Ultra with Tonga, both with Mesa 13.0.6
> and Git.
>
> Have you tried if Christian's patches for CPU access to split VRAM
> buffers help? I can imagine that forcing contiguous VRAM buffers for CPU
> access could cause lots of other BOs to be unnecessarily evicted from
> VRAM, if at least one of their fragments happens to be in the CPU
> visible part of VRAM.

I've finally tested latest amd-staging-4.9 and I'm very pleased. For
the first time, the Deus Ex benchmark has almost no hiccups. I've
never seen it so smooth. At one point, the MB/s BO move rate increase
to 200MB/s, stayed there for a couple of seconds, and then it dropped
to 0 again. The frame rate was OK-ish, so I guess the moves didn't
happen all at once. I also tested DiRT Rally and I haven't been able
to reproduce the low FPS with the consistently-high BO move rate that
I saw several months ago.

We could do some move throttling there for sure, but it's much better
than it ever was.

Marek
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 09/17] drm/amdgpu: take ownership of per-pipe configuration v2

2017-04-16 Thread Andres Rodriguez
Thanks for the info.

I'll test it as well on Monday.

Regards,
Andres

On Apr 16, 2017 1:26 AM, "Oded Gabbay"  wrote:

Hey Andres,

Yes, that patch indeed fixed the black screen on Alex's 4.12-wip, but
it still wouldn't boot with your entire patch-set. It would boot only
with patches 1-8.

I'll try to get a USB-to-serial dongle so I could try dump kernel
messages during boot but it will probably take some time.

Oded

On Sun, Apr 16, 2017 at 3:12 AM, Andres Rodriguez 
wrote:
> Hey Oded,
>
> I've had problems with 4.12-wip on its own. Just wanted to confirm if
> you picked up this fix for a bug in drm-next:
> "drm: Fix get_property logic fumble"
>
> Regards,
> Andres
>
> On Sat, Apr 15, 2017 at 8:37 AM, Oded Gabbay 
wrote:
>> On Fri, Apr 14, 2017 at 12:35 AM, Andres Rodriguez 
wrote:
>>> Make amdgpu the owner of all per-pipe state of the HQDs.
>>>
>>> This change will allow us to split the queues between kfd and amdgpu
>>> with a queue granularity instead of pipe granularity.
>>>
>>> This patch fixes kfd allocating an HDP_EOP region for its 3 pipes which
>>> goes unused.
>>>
>>> v2: support for gfx9
>>>
>>> Reviewed-by: Edward O'Callaghan 
>>> Reviewed-by: Felix Kuehling 
>>> Acked-by: Christian König 
>>> Signed-off-by: Andres Rodriguez 
>>
>> Hi Andres,
>> FYI, with your patchset rebased on alex's drm-next-4.12-wip, my Kaveri
>> machine won't boot the OS (Ubuntu 16.04).
>> I bisected your patch-set and the first bad patch is this one.
>>
>> Unfortunately, I don't have the means to dump kernel crashes before
>> the system boots.
>>
>> Thx,
>> Oded
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx