Commen=
t # 3
on bug 10324=
6
from kmk3.bugs@gm=
ail.com
Hello iive, thanks for the detailed response.
> Does the bug still happen with current mesa3d+ll=
vm?
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 i=
dea if you can create an apitrace recording of a place where the game crash=
es. 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).
>=20
> I usually place the apitrace wrapper d3d9.dll inside the game director=
y (main or where game.exe is). Then using `winecfg` add library override fo=
r "d3d9" to be "native, built-in".
> If everything goes well, the wrapper would create a new trace inside t=
he game directory every time the game is started. So don't forget to remove=
it when you are done.
>=20
> 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 i=
t.
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 m=
y card is using the R600 driver, so it is very unlikely to have the same sh=
ader 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/bug=
s.html
[2] https://www.mesa3d.or=
g/debugging.html
[3] https://github.com/apitrace/apitrace/blob/master/docs/USAGE.markd=
own
[4] https://wiki.ixit.cz/d3=
d9_debugging