Created attachment 106807 [details] System information text doc Two users (one of them myself) have experienced trouble with Tropico 5. "Last patch made it run the menu but starting the new game renders the system unusable and requires a reboot :( Last message in the system log is this: kernel: radeon 0000:01:00.0: ring 0 stalled for more than 10000msec GPU is Mobility Radeon HD 5730 with mesa 10.2.8 drivers on kernel 3.16.3." (steam fora) And me: "Tried both Tropico 5 main and linuxbeta, on intel i7 CPU 930 and AMD Radeon HD 5870. Had to work around the black screen issue but, upon reaching the main menu and clicking on New Campaign or Tutorial, the screen would flash and glitch and sound would repeat. After that, my monitor would turn on and off and display Refresh rate out of range (approx. 43.1 KHz - 41 Hz) and the system would need a cold reboot. Tried to run it with both the updated kernel and without, realising I had never let it run for more than 30 seconds after the freeze. Result was that the fans inside my computer began spinning like crazy, the system restarted with 4-5 ping sounds and the fans still running full-speed. Only after a cold shutdown did the fans stop. So I suspect this process almost fried my CPU or GPU." I am running updated Mesa and Gallium through oibaf ppa.
I'm the second user describing this issue on the Steam forum. Except it's r600g, not radeonsi for me. All latest stable packages from Arch Linux.
Those cards are r600g, not radeonsi. In general terms radeonsi is Radeon HD 7XXX and newer. I am using radeonsi mesa git (both with llvm-3.5 and llvm-3.6) with linux 3.17 rc5 and I am not experiencing that problem. In fact, I have been able to play for 3+ hours non-stop without any problem.
I also received this suggestion from the Kalypso support team: Dear Armandos, please disable post processing and enable v-sync in the options in game. Best regards. Following their instructions DID NOT fix the issue, unfortunately.
Same Problem for me with my HD 6870...
Same here with an HD6950. Here is the output i have from the terminal: New UI mode "Game" set in 0 ms VideoImpl::ReadAndDecodeFrame: skipped frames: 99 EE r600_shader.c:2494 r600_shader_from_tgsi - GPR limit exceeded - shader requires 132 registers EE r600_shader.c:158 r600_pipe_shader_create -translation from TGSI failed ! EE r600_state_common.c:758 r600_shader_select - Failed to build shader variant (type=1) -12 Map changed to "Maps/Isla grande lago T1". Lua memory in use: 21690 KB.
if launching with R600_DEBUG=notiling MESA_GL_VERSION_OVERRIDE=4.0 MESA_GLSL_VERSION_OVERRIDE=400 %command% no freeze anymore,and i can play :)
Works with notiling for me as well.
Created attachment 111658 [details] Testcase for R600g driver (Linux/x86-64). Just got same bug while testing various landscape rendering techniques. Screen is black and terminal is flooded with messages: EE r600_shader.c:158 r600_pipe_shader_create -translation from TGSI failed ! EE r600_state_common.c:757 r600_shader_select - Failed to build shader variant (type=2) -1 I'm using Linux Mint 17.1 Mate (based on Ubuntu 14.04 LTS), video card is AMD Radeon HD 6650M 2GB. I tested this on mesa 10.1.3 (system's default) and latest 10.5~git (using oibaf's ppa) versions, same story. I prepared a test application, checked it with other drivers to be sure it's working, and it is attached to this comment. If You need any more information feel free to ask me. Thanks, Leon.
Forgot to say, that I also tested with R600_DEBUG=notiling and R600_DEBUG=llvm: notiling - does not change anything. llvm - crash (memory corruption in glGenerateMipmap()).
(In reply to leonmaxx from comment #8) > Just got same bug while testing various landscape rendering techniques. Please file your own report about that. BTW, don't expect others to download random executables and run them on their systems. If you can't provide the source code for your test application, maybe you can generate an apitrace which reproduces the problem. Or, even just attaching the stderr output from running the app with R600_DEBUG=vs,gs,ps might be useful.
Is Valve's VOGL trace will be enough?
(In reply to leonmaxx from comment #11) > Is Valve's VOGL trace will be enough? Possibly.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/527.
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.