Plan: BO move throttling for visible VRAM evictions

Michel Dänzer michel at daenzer.net
Fri Apr 14 10:14:51 UTC 2017


On 04/04/17 05:11 AM, Marek Olšák wrote:
> On Fri, Mar 31, 2017 at 5:24 AM, Michel Dänzer <michel at daenzer.net> 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.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer




More information about the amd-gfx mailing list