| Bug ID | 97174 |
|---|---|
| Summary | Assault Android Cactus freezing on Mesa 12 |
| Product | Mesa |
| Version | git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | blackheart_pro@yahoo.com |
| QA Contact | dri-devel@lists.freedesktop.org |
I'm experiencing freezing in Assault Android Cactus on Ubuntu = 16.04 and Fedora 24. My video card is an AMD R9 Fury X.=20 When using Mesa 12.1 on Ubuntu 16.04 via Padoka PPA, I get guaranteed freez= ing between the start screen and the main menu. As in, when you start the game = and enter the main menu from the start screen, and then go back to the start screen, the game freezes. There's also freezes that occur during gameplay, = but I can't reliably reproduce those. Last freeze during gameplay was when I hit escape to get to the menu. Before I installed Ubuntu 16.04, I was using Fed= ora 24 and was also getting these issues on Fedora. Fedora 24 received Mesa 12 = via an update after release. None of these issues occurred with Ubuntu 16.04's stock Mesa build (11.2)=20 I got the suggestion that Mesa 13 was possibly too new for Ubuntu's stock kernel (4.6.3,) so i updated my kernel to 4.7, bu the issues still occurred= .
(In reply to blackheart_pro from comment #0) > I got the suggestion that Mesa 13 was possibly t= oo new for Ubuntu's stock My apologies, I meant to say Mesa 12 here. Obviously, Mesa 13 would be too = new for :P
For the reliably reproducible hangs: Can you record an apitrac= e and see if that reproduces the hang? Also, try running with GALLIUM_DDEBUG=3D1000 and provi= de the report from ~/ddebug_dumps/.
So I tried apitrace. Strangely, I can't get the hang to happen= anymore when running apitrace. Mind you, this is a Steam app. I use the command: DEBUGGER=3D"apitrace trace" steam steam://rungameid/250110 to boot up the game and Steam, but I can't get the reliable hang to happen anymore with apitrace. Same when GALLIUM_DDEBUG=3D1000 (aside from slow performance when doing this, but I assume this is normal because it's some = sort of debug environment, right?) When I run the game directly from the Steam client and use the steps I described to produce the hang, the hang happens. heh. I'm not sure what's happening.
Hi, I can't seem to reproduce any freezes with AAC here (R9 38= 0X, Gentoo, Mesa 6db93cd, LLVM r276989). I do see some reproducible stutter when getting to certain parts of the game for the first time after starting it, but that la= sts for less than a second - is that what you are talking about? (I don't get it when going back to the start screen, so probably not) Does the game only temporarily freeze and then continue, does it freeze permanently or does the whole system lock up? If (only) the game remains frozen, you can use the following command to see where it is stuck (you may need to install gdb first): gdb --pid `pidof cactus.x86_64` --batch -ex 'info threads' -ex 'thread app= ly all bt' Btw, the game also has a free demo on Steam - look for the Download Demo bu= tton on http://store.steam= powered.com/app/250110/ - but afaik that is quite a bit older than the full version now so it may or may not have the same issue.
Strange that you don't get a hang with apitrace. For the hang = not happening with the GALLIUM_DDEBUG setting, there are two possible explanations: 1. It might be a timing thing. With very recent Mesa you can try GALLIUM_DDEBUG=3D"pipelined 1000" instead, which should run at hi= gher performance. If that hangs, the resulting report should be just as good. 2. It might be that the hangs depend on not flushing. You can run GALLIUM_DDEBUG=3D"1000 noflush", which doesn't affect the flushin= g behaviour. It would be interesting to know if that still hangs, though unfortunately the = hang reports tend to be less useful.
The conclusion I'm coming to is it's almost certainly some kin= d of conflict with Steam; particularly when launching the game through Steam itself. AAC = is DRM free, it doesn't need Steam to run. When I run the game without Steam, I don't get any hangs at all. That's probably why I can't produce the hang wh= en running the command mentioned in com= ment 3. Using apitrace with that command, I don't believe it launches the game with the full Steam environment. Steam doesn't appear to be running in the background and I can't shift+tab to get= the overlay. I can't properly record the hang without Steam present, but I'm not sure how (or if i even can,) use apitrace + ACC with full Steam running as = if launched through the client. This also applies to GALLIUM_DDEBUG=3D1000 as = well. No hangs and it doesn't produce any files (they're supposed to appear in /ddebug_dumps/ in the home folder, correct?) (In reply to Daniel Scharrer from c= omment #4) > Does the game only temporarily freeze and then c= ontinue, does it freeze permanently or does the whole system lock up? Permanent. Only the game freezes. I can't even kill it when it does freeze, I've tried everything. Strange that you aren't getting it. Are you using Me= sa 12? That's the key here, Mesa 11 series doesn't suffer from this bug at all= .=20 > you can use the following command to see where i= t is stuck (you may need to install gdb first): >gdb --pid `pidof cactus.x86_64` --batch -ex 'info= threads' -ex 'thread apply all bt' gdb is installed by default in Ubuntu 16.04, but seems I can't get this com= mand to work.
If you have DRI3 enabled, does setting the environment variable LIBGL_DRI3_DISABLE=3D1 when launching steam avoid the hang? If so, how about LD_PRELOAD=3D'/usr/$LIB/libxcb.so.1':$LD_PRELOAD ?
(In reply to Michel D=C3=A4nzer from comment #7) > If you have DRI3 enabled, does setting the envir= onment variable LIBGL_DRI3_DISABLE=3D1 when launching steam avoid the hang?= If so, how about LD_PRELOAD=3D'/usr/$LIB/libxcb.so.1':$LD_PRELOAD ? Looks like both of these work. no hanging when launching AAC through Steam = and performing the usual steps.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | NOTOURBUG |
The problem is caused by the Steam runtime shipping an old ver= sion of libxcb, which has a bug causing DRI3 apps to hang randomly.
Oooh, that makes sense. Steam is the culprit, as suspected. Th= anks, Michel D=C3=A4nzer! Looks like this is on Valve. Guess I should contact them.
| What | Removed | Added |
|---|---|---|
| CC | tmp6154@yandex.ru |
*** Bug 97428 has been marked as a dupl= icate of this bug. ***
| What | Removed | Added |
|---|---|---|
| CC | 375gnu@gmail.com |
*** Bug 98705 has been marked as a dupl= icate of this bug. ***
https://github.com/ValveSoftware/steam-for-linux/issues/4638=