Bug 103246

The symptoms are typical for shader infinite loop, followed by botched driver restart. Definitely not Wine fault.

Does the bug still happen with current mesa3d+llvm?

While the game is free, it would still be good idea if you can create an apitrace recording of a place where the game crashes. Ask in #d3d9 at irc.freenode about the ftp access, or use google drive or similar file sharing. (We might use the trace for regression testing in future).
It might be good idea if you also fill bugreport to the github Ixit/Mesa-3D issue tracker.

I usually place the apitrace wrapper d3d9.dll inside the game directory (main or where game.exe is). Then using `winecfg` add library override for "d3d9" to be "native, built-in".
If everything goes well, the wrapper would create a new trace inside the game directory every time the game is started. So don't forget to remove it when you are done.

Naturally, use working mesa3d version for the trace. Then install new version of mesa and check if the trace crashes.

If you can compile mesa3d on your own, you might be able to help narrow down the problem further. I cannot do that, since my card is using the R600 driver, so it is very unlikely to have the same shader miscompilation.

I just sow that there is already issue opened for the same/similar issue:

https://github.com/iXit/Mesa-3D/issues/296

Hello iive, thanks for the detailed response.

> Does the bug still happen with current mesa3d+llvm?
I tested briefly a week after you commented and it no longer occurred with mesa
17.3.8 :)

# Packages:
linux416 4.16.0-1

lib32-llvm-libs 6.0.0-1
llvm-libs 6.0.0-4

lib32-mesa 17.3.8-1
lib32-mesa-vdpau 17.3.8-1
libva-mesa-driver 17.3.8-1
mesa 17.3.8-1
mesa-vdpau 17.3.8-1

wine-gaming-nine 3.5-2

# ----------

I just got around to recompiling the latest nine and testing with the latest
mesa, to make sure it still works and it does.

# Packages:
linux416 4.16.4-1

lib32-llvm-libs 6.0.0-1
llvm-libs 6.0.0-4

lib32-mesa 18.0.1-1
lib32-mesa-vdpau 18.0.1-1
libva-mesa-driver 18.0.1-1
mesa 18.0.1-1
mesa-vdpau 18.0.1-1

wine-gaming-nine 3.7-1

# ----------

> It might be good idea if you also fill bugreport to the github Ixit/Mesa-3D issue tracker.
This is something I'm still not sure about: Where is it appropriate to file
bugs?
Considering the next time I find a bug with increased likelihood of it being
in mesa, should it be reported on each project (mesa, wine and nine) for
tracking or would it just add noise?

> While the game is free, it would still be good idea if you can create an apitrace recording of a place where the game crashes. Ask in #d3d9 at irc.freenode about the ftp access, or use google drive or similar file sharing. (We might use the trace for regression testing in future).
> 
> I usually place the apitrace wrapper d3d9.dll inside the game directory (main or where game.exe is). Then using `winecfg` add library override for "d3d9" to be "native, built-in".
> If everything goes well, the wrapper would create a new trace inside the game directory every time the game is started. So don't forget to remove it when you are done.
> 
> Naturally, use working mesa3d version for the trace. Then install new version of mesa and check if the trace crashes.
Thanks for the details, I was struggling on finding a proper way to debug it.
Now digging through the mesa website, I found the mention of apitrace on [1],
but not on [2], while the debugging build instructions are only on [2].
It seems to me that it would make sense to merge the pages together.

Also, that's an interesting approach that seems to differ a little from [3].
Would you mind documenting it if/when you have the time?
As someone new to debugging graphics drivers, it seems like information is a
bit scattered around different pages and projects.
It would be quite helpful to have instructions for a general debugging
workflow centralized in one place.
But I digress.

> If you can compile mesa3d on your own, you might be able to help narrow down the problem further. I cannot do that, since my card is using the R600 driver, so it is very unlikely to have the same shader miscompilation.
For future reference, I managed to recompile mesa and wine-staging-nine
(or wine-gaming-nine) months ago (around November by the log date) with all
the debug flags in [4].
But even then, the only lines ever logged to MESA_LOG_FILE were these
(repeated ~1k times):
Mesa: User error: GL_INVALID_OPERATION in glResumeTransformFeedback(wrong program bound)
Mesa: User error: GL_INVALID_OPERATION in glPauseTransformFeedback(feedback not active or already paused)

Maybe it was a really catastrophic error.

[1] https://www.mesa3d.org/bugs.html
[2] https://www.mesa3d.org/debugging.html
[3] https://github.com/apitrace/apitrace/blob/master/docs/USAGE.markdown
[4] https://wiki.ixit.cz/d3d9_debugging

(In reply to iive from comment #2)
> I just sow that there is already issue opened for the same/similar issue:
> 
> https://github.com/iXit/Mesa-3D/issues/296
Good catch, just commented in there and linked to this bug.