From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 103246] PoE: GPU hang with mesa >= 17.2.0 + gallium-nine
Date: Sun, 13 May 2018 17:50:00 +0000 [thread overview]
Message-ID: <bug-103246-502-7DasLMrBLa@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-103246-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 4025 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=103246
kmk3.bugs@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #3 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.
[-- Attachment #1.2: Type: text/html, Size: 5882 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-05-13 17:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 18:20 [Bug 103246] PoE: GPU hang with mesa >= 17.2.0 + gallium-nine bugzilla-daemon
2018-04-11 18:11 ` bugzilla-daemon
2018-04-11 18:21 ` bugzilla-daemon
2018-05-13 17:50 ` bugzilla-daemon [this message]
2018-05-13 18:12 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-103246-502-7DasLMrBLa@http.bugs.freedesktop.org/ \
--to=bugzilla-daemon@freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.