| Bug ID | 86720 |
|---|---|
| Summary | Europa Universalis 4 freezing during game start (10.3.3) |
| Product | Mesa |
| Version | 10.3 |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/r600 |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | buchno@riseup.net |
Created attachment 110028 [details]
134220 line strace from loading game to freeze to force quit.
Europa Universalis 4 stops responding after loading from pressing "Play" in the
nation select screen.
Not present in Mesa 10.3.2, the problem was introduced in 10.3.3.
Related to the radeon driver, as the Intel driver works without issue.
OS: Arch Linux
GPU: Radeon HD 6950
GPU Driver: xf86-video-ati 7.5.0
CPU: Intel i5-2500K
| What | Removed | Added |
|---|---|---|
| CC | felix.schwarz@oss.schwarz.eu | |
| Blocks | 77449 |
| What | Removed | Added |
|---|---|---|
| Summary | Europa Universalis 4 freezing during game start (10.3.3) | [radeon] Europa Universalis 4 freezing during game start (10.3.3) |
After a couple of hours of compiling... Commit e8c7affa66407932519fc6d82a449b453343d9fc works fine. Commit d26258166ca056da62536bebdf107e21d9ce92fb introduces the issue.
It looks like the R600 driver cannot handle some loops and han= gs (in an infinite loop probably). There are some new fixes for Cayman in the master branch. Can you apply them and see if they help? http://cgit.freedesktop.org/mesa/mesa/log?qt=3Dgrep&q=3Dr600
Commit 133280120b4bc714bbb7665e383f36ab262c280a, after the fixes for Cayman in master, still has the issue. Or did you mean of me to cherry-pick specific fixes?
(In reply to glwhieuhghfbjds from comment #4) > Commit 133280120b4bc714bbb7665e383f36ab262c280a,= after the fixes for Cayman > in master, still has the issue. >=20 > Or did you mean of me to cherry-pick specific fixes? No. It looks like Cayman still has some bugs.
Actually, i'm having this issue as well with a HD5850. So it's probably not Cayman specific OS: Arch Linux GPU:Radeon HD5850 Mesa 10.3.5 and 10.5git(last tested about a week ago) CPU:Phenom 2 X3 720
Same issue with HD5730 and mesa git: Mesa 10.5.0-devel (git-8d2542f). Tried turning off every available graphics option in the game and using "notiling" (which helped with a similar GPU lockup in Tropico 5) but nothing.
Created attachment 111977 [details]
Part of the log during the lockup
Messages in the attached part of the log are repeating for a while, with
monitors going off and on. Eventually the system is usable for a while and then
just locks up for good, requiring a hard reset.
Having the same issue with HD5650. When using mesa 10.2.8 ther= e was no problem, but when I upgraded to mesa 10.4.2 the entire system froze after loading a game, either new or saved. OS: Gentoo amd64 GPU: Radeon HD5650 GPU driver: xf86-video-ati 7.5.0 Mesa: 10.4.2 CPU: intel i3 M370
I can confirm that the issue was introduced (on master) with t= his commit: commit 6fcb5520b78cdf1e5013c125501932315a069955 Author: Marek Ol=C5=A1=C3=A1k <marek.olsak@amd.com> Date: Tue Oct 28 19:49:44 2014 +0100 Revert "st/mesa: set MaxUnrollIterations =3D 255" This reverts commit 20836c81851e0df29a8ee9c86e5e5388738c840b. 255 is a huge number. If you have a loop with 255 iterations, unrolling= it will exceed the SM3 instruction limit. Let's use the default again. The comment about a SM3 limit doesn't make sense. For SM3, we generally want 32 (default) or a lower number due to the SM3 instruction limit, w= hich is 512 instructions. For SM4, we can try higher numbers if needed, but some shaders can end up being pretty huge and shader compilation can ta= ke more time. This fixes a shader compile failure on R500/SM3. Reported on IRC. Cc: 10.2 10.3 <mesa-stable@lists.freedesktop.org> Reviewed-by: Brian Paul <br= ianp@vmware.com> Marek: You mentioned that the r600 driver might be unable to handle certain loops. Is there anything the community can do to get this fixed? apitrace? Checking for piglit regressions related to the mentioned commit? I assume t= hat you would be able to fix this much better if you could reproduce the problem easily.
I'd add a PIPE_CAP and allow the driver to set MaxUnrollIterat= ions with it. For r600g, the old value should be used. For other drivers, the new value shoul= d be used.
(In reply to Marek Ol=C5=A1=C3=A1k from comment #11) > I'd add a PIPE_CAP and allow the driver to set M= axUnrollIterations with it. "I'd add" as in "I plan to add" or as in "someone = else should fix that by ..."?
For what it is worth, a temporary workaround would be setting = R600_DEBUG=3Dnosb. I saw that in a comment about bug #88263 and it turns out to work= .
Created attachment 113246 [details]<=
/span> [review]
patch
Hi guys, could you please test this patch?
I applied your patch on top of mesa 7ea1e3749738c63388d3bcca327e4e4dd28f17b8 with llvm 3.5 and linux 3.18.5 and I can confirm that this problem fixes the original problem as expected. One thing that bothers me personally is that no piglit test went bad when the initial change was committed. Marek do you think it would be a good idea as a newbie project to come up with a minimal api trace and try to build a piglit test preventing that kind of problem or is that likely to be a fruitless effort?
Having a piglit test reproducing the issue would be very usefu= l.
I can confirm the patch fixes the issue here as well
I created an API trace which reproduces the problem for me (https://dl.dropboxusercontent.com/s/hc6v7gdcshj4ljd/eu4.trace-lockup.xz?dl=0 , 120 MB, unfortunately trimming produces only invalid states). The shaders itself don't look to bad to me but I don't have any experience deducing a miminal testcase from an apitrace (pointers welcome).
| What | Removed | Added |
|---|---|---|
| CC | maraeo@gmail.com |
(removing myself from the Cc list, already getting emails from= dri-devel)