Bug 92923 - SGPR spilling
Summary: SGPR spilling
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: 11.0
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-12 18:26 UTC by pat
Modified: 2016-08-24 21:32 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
stacktrace from game log file (2.28 KB, text/plain)
2015-11-12 18:26 UTC, pat
Details
backtrace from game log file (1.87 KB, text/plain)
2015-11-12 18:27 UTC, pat
Details
Game log file (6.61 MB, text/plain)
2015-11-19 17:36 UTC, pat
Details
fix long buffer wait times observed in trace (3.39 KB, patch)
2016-01-09 23:21 UTC, Nicolai Hähnle
Details | Splinter Review
always add GTT to buffers' initial domain (1007 bytes, patch)
2016-01-12 14:48 UTC, Nicolai Hähnle
Details | Splinter Review

Description pat 2015-11-12 18:26:22 UTC
Created attachment 119606 [details]
stacktrace from game log file

"LLVM triggered Diagnostic Handler: Ran out of VGPRs for spilling SGPR"

The game Planet Explorers crashes after a few minutes, the log file is flooded with this error message.

Additional error messages:
radeon_llvm_compile: Processing Diag Flag
LLVM failed to compile shader
EE si_state_shaders.c:647 si_shader_select - Failed to build shader variant (type=1) 1

The problem may have started with mesa 11.0 but I'm not sure, I don't play it very often. The game runs on unity 5.

Attaching backtrace and stacktrace from the log file. There is also a memory map I could attach.

OpenGL info from the log file:
Version:  OpenGL 3.0 [3.0 Mesa 11.0.5]
Renderer: Gallium 0.4 on AMD PITCAIRN (DRM 2.43.0, LLVM 3.7.0)
Vendor:   X.Org
VRAM:     2048 MB

Hardware is a Radeon HD 7870
Comment 1 pat 2015-11-12 18:27:10 UTC
Created attachment 119607 [details]
backtrace from game log file
Comment 2 Michel Dänzer 2015-11-19 02:38:38 UTC
Tom, any ideas?

pat, please run the game with the environment variable R600_DEBUG=vs,gs,ps and attach its stderr output after reproducing the problem.
Comment 3 pat 2015-11-19 17:36:13 UTC
Created attachment 119948 [details]
Game log file

Steam seems to mess with stderr, I hope this game log has the info you need.
Comment 4 Michel Dänzer 2015-11-20 09:07:55 UTC
(In reply to pat from comment #3)
> Steam seems to mess with stderr, I hope this game log has the info you need.

It does, thanks.
Comment 5 pat 2016-01-09 12:12:02 UTC
Version:  OpenGL 3.0 [3.0 Mesa 11.2.0-devel (git-bca1805)]
Renderer: Gallium 0.4 on AMD PITCAIRN (DRM 2.43.0, LLVM 3.8.0)

No more crashes with the current game version and mesa git/llvm svn, but it runs with 1 FPS (with very rare boosts to 45-60 FPS) on lowest settings. The log file still looks like before as far ar I can tell.

This was probably my last test with AMD/mesa.
Comment 6 Nicolai Hähnle 2016-01-09 16:46:28 UTC
Sorry for your pain. We did make some changes to make LLVM more robust recently, so that's something. As for the performance problems you're seeing, I'd really appreciate if you could provide an apitrace, see https://github.com/apitrace/apitrace/wiki/Steam if you're running the game under Steam. That should allow us to reproduce the issue.
Comment 7 pat 2016-01-09 20:09:29 UTC
llvm svn version 257076 (32bit: 257085)
OpenGL 3.0 [3.0 Mesa 11.2.0-devel (git-040e314)]
apitrace: http://www.psycho3d.de/temp/PlanetExplorersApitrace.7z (300MB 7zipped)

Apitrace should include a few minutes of gameplay, 2x freeze for several seconds. I disabled the steam overlay for the trace but I think I had probably 1-3 FPS during the test.
Comment 8 Nicolai Hähnle 2016-01-09 23:21:11 UTC
Created attachment 120923 [details] [review]
fix long buffer wait times observed in trace

Hi pat, thanks for following up with this!

On Tonga, this trace runs into a variant of the compiler error you mentioned earlier in the bug report due to limited SGPRs. This is something we still need to address.

On Carrizo, I can run the trace and I notice an obvious buffer wait time problem. Please try the quick-and-dirty patch I've attached. The trace is still slow for me, but (a) it's a trace and (b) it's not a dGPU part, so I'd be interested to hear how the in-game performance is for you with the patch.
Comment 9 pat 2016-01-10 11:11:44 UTC
Hey Nicolai, thanks for the fast patch.

I've patched rev 5e3edd4 of the 32bit package (lib32-mesa-git, lib32-mesa-git-debug, lib32-mesa-libgl-git) and started the 32bit game binary. It's still at 3-4 FPS.
Comment 10 pat 2016-01-11 16:47:34 UTC
Any last tests you'd want me to do before I upgrade my hardware and say bye bye to AMD?
Comment 11 Nicolai Hähnle 2016-01-12 04:24:12 UTC
With the branch at http://cgit.freedesktop.org/~nh/mesa/log/?h=pub-invalidate the in-game part of your trace plays back at around 11 FPS on a Carrizo, which is an integrated GPU (laptop). It may be worth a shot.
Comment 12 Nicolai Hähnle 2016-01-12 14:48:00 UTC
Created attachment 120987 [details] [review]
always add GTT to buffers' initial domain

How much VRAM do you have? Try running the game with GALLIUM_HUD=num-bytes-moved, with and without the attached patch.
Comment 13 pat 2016-01-12 18:46:51 UTC
2048M VRAM

Test 1:
Version:  OpenGL 3.0 [3.0 Mesa 11.2.0-devel (git-6f898f7)]
Patched with both patches you provided.

With patch: the graph spikes up to 45.5 MB during the loading screen, later it stays at 0 byte. When I turn around it goes up to KB but not MB. Still around 3 FPS, up to 11 when looking at the sky.
Comment 14 pat 2016-01-12 20:16:19 UTC
Test 1: no noticeable difference between patched and not.

Test 2: your repo/branch (git-016eba7), no noticeable improvement (including the GTT patch). Graph also shows minimal bytes moved.
Comment 15 Marek Olšák 2016-08-24 21:32:52 UTC
Fixed a long time ago.


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.