https://bugs.freedesktop.org/show_bug.cgi?id=103246
kmk3.b...@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from kmk3.b...@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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
