| Summary: | Performance regression with various games in drm-next-amd-staging Kernel | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Gregor Münch <gr.muench> |
| Component: | Drivers/Gallium/radeonsi | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED FIXED | QA Contact: | Default DRI bug account <dri-devel> |
| Severity: | normal | ||
| Priority: | medium | CC: | adf.lists, ckoenig.leichtzumerken, vedran |
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Shadow of Mordor benchmark current amd-staging kernel
Shadow of Mordor benchmark older amd-staging kernel Shadow of Mordor benchmark current amd-staging kernel shader cache |
||
|
Description
Gregor Münch
2017-10-04 16:38:21 UTC
Thanks for the report. The bisection result makes perfect sense, as the version bump can change how Mesa behaves. Could you please provide the version of Mesa you're using? (The output of glxinfo contains this.) I tested again with yesterdays git and newer Kernel: OpenGL renderer string: AMD Radeon HD 7900 Series (TAHITI / DRM 3.21.0 / 4.14.0-2-drm-next-dc-git, LLVM 6.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.0-devel (git-0c1aecf177) The system doesnt hang anymore, it completes phoronix benchmark runs again. Before it was always crashing when the 3rd game test was started. The benchmark suite let the games run 3 times each test. So it usually crashed after 7-8 starts. However I still see those GPU faults in the log. Performance in Shadow of Mordor is still just 61-62fps. I did a rather lengthy test with some games: https://openbenchmarking.org/result/1711211-AL-GAMETEST345 To conclude, it is slower for everything game I tested. Dota2 Vulkan and Unigine Superposition are one of the larger drops. This correlates to findings from phoronix btw: https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DRM-4.15-Early One possible issue with per-VM BOs is that the kernel driver can no longer migrate BOs to more optimal placement for a command stream, because it doesn't know which BOs are used by the command stream. So if e.g. a per-VM BO is evicted from VRAM, e.g. due to CPU access to it, it will normally never move back to VRAM. Christian, might it be possible to e.g. maintain a list of per-VM BOs which were evicted from VRAM, and try to move them back to VRAM as part of the existing mechanism for this (for "normal" BOs)? *** Bug 103175 has been marked as a duplicate of this bug. *** (In reply to Michel Dänzer from comment #4) > Christian, might it be possible to e.g. maintain a list of per-VM BOs which > were evicted from VRAM, and try to move them back to VRAM as part of the > existing mechanism for this (for "normal" BOs)? That would certainly be possible, but I don't think it would help in any way. The kernel simply doesn't know any more which BOs are currently used and which aren't. So as soon as userspace allocates more VRAM than physical available we are practically lost. In other words we would just cycle over a list of BOs evicted from VRAM on every submission and would rarely be able to move something back in. What we could do is try to move buffers back into VRAM when memory is freed, but that happens so rarely as well that it probably doesn't make much sense either. Can somebody analyze exactly why those games are now slower than they have been before? E.g. which buffers are fighting for VRAM? Or are they maybe fighting for GTT? Created attachment 135672 [details]
Shadow of Mordor benchmark current amd-staging kernel
This is current situation...
I dont know if this helps.
Created attachment 135673 [details]
Shadow of Mordor benchmark older amd-staging kernel
Created attachment 135674 [details]
Shadow of Mordor benchmark current amd-staging kernel shader cache
This is the situation after the shader cache kicked in. Seems to be not any different.
Ive updated test, with staging kernel and mesa from today: https://openbenchmarking.org/result/1712028-AL-GAMETEST322 Looks like I enabled performance governor by accident. But overall 4.11 is still faster- so it looks like there were some performance improvements in mesa in the last days. For my test case - UnrealTournament alpha + not quite enough vram, looks like mesa commit winsys/amdgpu: disable local BOs again due to worse performance https://cgit.freedesktop.org/mesa/mesa/commit/?id=bf0904e31fb7d9cd8932d582076c8d7beb02ba89 works around the issue. Ive tested Shadow of Mordor and something in the last two weeks made it faster, either Kernel or Mesa or LLVM. Basically it went from 61/63 fps to 66 fps. With Mesa from today, performance is restored to 68 fps. Ive also ran my test suite again: https://openbenchmarking.org/result/1712125-AL-GAMETEST346 Especially Unigine Superposition saw great benefit and went from 40 to 49 fps. Dota 2 vulkan is still in a regressed state. Ive also made a trace file with Shadow of Mordor with older kernel and good performance some days ago: https://uploadfiles.io/ktjmx I still struggle to compress the trace with the "bad" performance, if you guys are interested I try to provide it. Marking resolved for now. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.