| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |
Comment # 3
on bug 103246
from kmk3.bugs@gmail.com
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
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
