On 17/04/17 07:58 AM, Marek Olšák wrote: > On Fri, Apr 14, 2017 at 12:14 PM, Michel Dänzer <michel at daenzer.net> wrote: >> 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. > > 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. That's great to hear. If you get a chance, it would be interesting if the attached updated patch improves things even more for you. (The patch I attached previously couldn't work as intended, this one at least might :) -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -------------- next part -------------- A non-text attachment was scrubbed... Name: amdgpu-visible-VRAM-evict.diff Type: text/x-patch Size: 1780 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20170417/3d671394/attachment.bin>
