https://bugs.freedesktop.org/show_bug.cgi?id=34969
Summary: [nouveau] Card lockup on openarena Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: mad.f3ka@gmail.com
Created an attachment (id=44068) --> (https://bugs.freedesktop.org/attachment.cgi?id=44068) messages.log part
Each time I try to start openarena or any other game, card locks up (not in menu, but in game).
I'm not sure, but log in messages seems to be related to this issue (see messages attachment).
Software versions: kernel 2.6.37.2 libdrm 2.4.23 mesa 7.10.1 xf86-video-nouveau 0.0.16_git20101217
Hardware: 06:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600] (rev a2)
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #1 from Andrew Randrianasulu randrik@mail.ru 2011-07-14 22:40:18 PDT --- While nvfx (3d gallium driver) isn't supported, i run few tests with nouveau-git (commit 72690683e35680d912e9b8ff2ee0b7a18631dd0d - "drm/nouveau/pm: Document and expose CL and WR for 0x1002Cx") and mesa-7.12-devel (OpenGL version string: 2.1 Mesa 7.12-devel (git-a09b7f7)).
Other software - Q3 Arena linux demo.
Results kinda strange.
Default settings Timedemo 1 demo demo002 - lock up card very fast, can power off machine via ACPI. demo demo001 - works!
geometry detail set to low demo demo001 - not tested demo demo002 - works!
geometry detail set to medium demo demo002 - lock up after some time (not at start of level)
For perflvl=0
even demo001 lock up after some time in the middle (always at same place).
So, I guess we run ahead or behind GPU, mostly in sending geometry data? need more test with perf mesa demos, for example ....
currently my performance levels are
drm] nouveau 0000:01:00.0: mem timing table length unknown: 14 [drm] nouveau 0000:01:00.0: 2 available performance level(s) [drm] nouveau 0000:01:00.0: 0: core 300MHz memory 1000MHz voltage 1300mV fanspeed 100% [drm] nouveau 0000:01:00.0: 1: core 500MHz memory 1000MHz voltage 1400mV fanspeed 100% [drm] nouveau 0000:01:00.0: c: core 100MHz memory 501MHz voltage 1300mV [TTM] Zone kernel: Available graphics memory: 255992 kiB.
and perflvl 1 lock up whole machine pretty fast (before i managed to run any bench, even with just composited, via Xrender/Kde 3.5.10 desktop)
Guess I need additional "bug" for tracking this. And probably one more for tracking invisible VTs after s3 sleep ....
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #2 from Andrew Randrianasulu randrik@mail.ru 2011-07-14 22:41:58 PDT --- Created an attachment (id=49119) --> (https://bugs.freedesktop.org/attachment.cgi?id=49119) nouveau dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #3 from Andrew Randrianasulu randrik@mail.ru 2011-07-14 23:21:33 PDT --- OK, perf/vertexrate lockup card.
If I disable (in vertexrate.c) everything, but immediate mode, i have
guest@slax:~/botva/src/demos/src/perf$ ./vertexrate Vertex rate (10000 x Vertex4f) Immediate mode: 11.2 million verts/sec
perf/vbo works, but as far as I can see it doesn't draw anything visible.
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #4 from Andrew Randrianasulu randrik@mail.ru 2011-07-14 23:43:39 PDT --- Ok, VBO glDrawArrays works too:
guest@slax:~/botva/src/demos/src/perf$ ./vertexrate Vertex rate (10000 x Vertex4f) Immediate mode: 11.5 million verts/sec VBO glDrawArrays: 12.8 million verts/sec guest@slax:~/botva/src/demos/src/perf$
Uncommenting anything else lock up card.
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #5 from Andrew Randrianasulu randrik@mail.ru 2011-07-16 17:23:02 PDT --- Created an attachment (id=49192) --> (https://bugs.freedesktop.org/attachment.cgi?id=49192) log of buffer activity, from NVFX_TRACE_DRAW=1 ./vertexrate > NV_TRACE.log 2>&1
https://bugs.freedesktop.org/show_bug.cgi?id=34969
Andrew Randrianasulu randrik@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #49192|text/plain |application/octet-stream mime type| |
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #6 from Andrew Randrianasulu randrik@mail.ru 2011-07-19 20:27:50 PDT --- Sorry, in my case aux. power was NOT connected to card. Now fastest perflevel works for Q3/demo001 (up to 78.0 fps for 1280x1024x32@60, but GPU temp raised to 92 C).
But unmodified vertexrate demo still freezes card even with default boot clocks :[
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #7 from Christoph Bumiller e0425955@student.tuwien.ac.at 2011-07-20 02:58:54 PDT --- Try cutting the vertexrate demo down to a minimal subset that causes the lockup and trace the command buffer. You're getting DMA_VTX_PROTECTION so you're likely accessing out of bounds vertex data somehow. If you can find the commands that cause it and compare with the gallium code you might be able to find the error.
Attached patch for tracing command buffer (apply to libdrm).
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #8 from Christoph Bumiller e0425955@student.tuwien.ac.at 2011-07-20 03:00:34 PDT --- Created an attachment (id=49332) View: https://bugs.freedesktop.org/attachment.cgi?id=49332 Review: https://bugs.freedesktop.org/review?bug=34969&attachment=49332
patch for libdrm command buffer tracing
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #9 from Andrew Randrianasulu randrik@mail.ru 2011-07-20 03:23:05 PDT --- Created an attachment (id=49333) --> (https://bugs.freedesktop.org/attachment.cgi?id=49333) Minimal vertexrate.c
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #10 from Andrew Randrianasulu randrik@mail.ru 2011-07-20 03:24:34 PDT --- Created an attachment (id=49334) --> (https://bugs.freedesktop.org/attachment.cgi?id=49334) NOUVEAU_TRACE.log
for channel 3
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #11 from Andrew Randrianasulu randrik@mail.ru 2011-07-20 04:39:31 PDT --- (In reply to comment #8)
Created an attachment (id=49332)
View: https://bugs.freedesktop.org/attachment.cgi?id=49332 Review: https://bugs.freedesktop.org/review?bug=34969&attachment=49332
patch for libdrm command buffer tracing
And how to parse this trace into more human-readable format? demmio from envytools?
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #12 from Andrew Randrianasulu randrik@mail.ru 2011-07-20 04:41:04 PDT --- Ops, i mean ./dedma . I was unable to find anything useful
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #13 from Andrew Randrianasulu randrik@mail.ru 2011-08-02 04:06:28 PDT --- More info.
When I set NVFX_SWTNL=1 ./vertexrate it also works without lockup. I was playing with amount of vertex data, and found what defining MAX_VERTS up to 1263 works OK, but 1264 and up lead to card lock-up.
So, i traced two cases, and diff'ed first full trace (with lockup) and part of second trace (33 Mb big, due to successful execution of test).
https://bugs.freedesktop.org/show_bug.cgi?id=34969
Andrew Randrianasulu randrik@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #49333|0 |1 is obsolete| |
--- Comment #14 from Andrew Randrianasulu randrik@mail.ru 2011-08-02 04:07:19 PDT --- Created an attachment (id=49823) --> (https://bugs.freedesktop.org/attachment.cgi?id=49823) modified vertexrate.c
https://bugs.freedesktop.org/show_bug.cgi?id=34969
Andrew Randrianasulu randrik@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #49334|0 |1 is obsolete| |
--- Comment #15 from Andrew Randrianasulu randrik@mail.ru 2011-08-02 04:10:22 PDT --- Created an attachment (id=49824) --> (https://bugs.freedesktop.org/attachment.cgi?id=49824) NOUVEAU_TRACE logs
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #16 from Andrew Randrianasulu randrik@mail.ru 2011-11-14 15:16:55 PST --- So, I bisected mesa tree (7.11 branch)
Result:
2a904fd6a0cb80eec6dec2bae07fd8778b04caf3 is the first bad commit commit 2a904fd6a0cb80eec6dec2bae07fd8778b04caf3 Author: Marek OlЕЎГЎk maraeo@gmail.com Date: Sun Dec 26 04:30:51 2010 +0100
st/mesa: set vertex arrays state only when necessary
The vertex arrays state should be set only when (_NEW_ARRAY | _NEW_PROGRAM) is dirty. This assumes user buffer content is mutable, which will be sorted out in the next commit. The following usage case should be much faster now:
for (i = 0; i < 1000; i++) { glDrawElements(...); }
Or even:
for (i = 0; i < 1000; i++) { glSomeStateChangeOtherThanArraysOrProgram(...); glDrawElements(...); }
The performance increase from this may be significant in some apps and negligible in others. It is especially noticable in the Torcs game (r300g): Before: 15.4 fps After: 20 fps
Also less looping over attribs in st_draw_vbo yields slight speed-up in apps with lots of glDraw* calls.
:040000 040000 45e5630d445206ce8c7eab6ac6bfe144901695bb 927efd20e354ecae459227bd464dbb6001cb448e M src
guest@slax:~/botva/src/src/mesa$ git bisect log git bisect start # good: [0f7325b89038937bd428f7c89ed9859189a0ab0b] i965: Emit texel offsets in sampler messages. git bisect good 0f7325b89038937bd428f7c89ed9859189a0ab0b # bad: [8767fe2437094f33db140a6b92f25116de4fc371] mesa: Sort extensions in extension string by year. git bisect bad 8767fe2437094f33db140a6b92f25116de4fc371 # bad: [fbd681f1a03f6ad62432107dc94e02674f6de7bf] i915g: Use dump function in sw winsys git bisect bad fbd681f1a03f6ad62432107dc94e02674f6de7bf # good: [1f5b67416810f7331fe71db0f767418473083701] egl_dri2: add nouveau support. git bisect good 1f5b67416810f7331fe71db0f767418473083701 # bad: [e0481cac7d57757d75a39763a1dd36b915979bb4] svga: Disable surface cache for textures git bisect bad e0481cac7d57757d75a39763a1dd36b915979bb4 # bad: [fc5ab1b19780ef97c5e7f6257a2d91121503bd53] mesa: use gl_format type instead of GLuint git bisect bad fc5ab1b19780ef97c5e7f6257a2d91121503bd53 # bad: [56029ce52bafbc51b5b6660383767257b7770cd7] r300g: inline some of the pipe_buffer_map/unmap calls git bisect bad 56029ce52bafbc51b5b6660383767257b7770cd7 # good: [9e96ea0652dda64f8eb311d7dfc9c50519ad02f0] r600g: add alignment cases for linear aligned git bisect good 9e96ea0652dda64f8eb311d7dfc9c50519ad02f0 # bad: [588fa884d212eba5ffbc69fda75db37d7c77214c] gallium: notify drivers about possible changes in user buffer contents git bisect bad 588fa884d212eba5ffbc69fda75db37d7c77214c # good: [cfaf217135d8a8e903b3fbf380f18170df018f0c] vbo: bind arrays only when necessary git bisect good cfaf217135d8a8e903b3fbf380f18170df018f0c # good: [cdca3c58aa2d9549f5188910e2a77b438516714f] gallium: remove pipe_vertex_buffer::max_index git bisect good cdca3c58aa2d9549f5188910e2a77b438516714f # bad: [2a904fd6a0cb80eec6dec2bae07fd8778b04caf3] st/mesa: set vertex arrays state only when necessary git bisect bad 2a904fd6a0cb80eec6dec2bae07fd8778b04caf3
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #17 from Marek Olšák maraeo@gmail.com 2011-11-14 15:28:23 PST --- (In reply to comment #16)
So, I bisected mesa tree (7.11 branch)
Result:
2a904fd6a0cb80eec6dec2bae07fd8778b04caf3 is the first bad commit commit 2a904fd6a0cb80eec6dec2bae07fd8778b04caf3 Author: Marek OlЕЎГЎk maraeo@gmail.com Date: Sun Dec 26 04:30:51 2010 +0100
st/mesa: set vertex arrays state only when necessary
I guess the bisection failed in this case, because that commit contains a bug that was fixed later.
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #18 from Andrew Randrianasulu randrik@mail.ru 2011-11-14 16:06:19 PST --- (In reply to comment #17)
(In reply to comment #16)
So, I bisected mesa tree (7.11 branch)
Result:
2a904fd6a0cb80eec6dec2bae07fd8778b04caf3 is the first bad commit commit 2a904fd6a0cb80eec6dec2bae07fd8778b04caf3 Author: Marek OlЕЎГЎk maraeo@gmail.com Date: Sun Dec 26 04:30:51 2010 +0100
st/mesa: set vertex arrays state only when necessaryI guess the bisection failed in this case, because that commit contains a bug that was fixed later.
gallium: notify drivers about possible changes in user buffer contents ? It was well-masked for Q3 arena until extension sorting exposed it there, but I run my ./vertexrate (reduced) test, and you can see whole bisect log... May be nvfx played too much with mesa/gallium internals.
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #19 from Andrew Randrianasulu randrik@mail.ru 2011-11-14 16:36:06 PST --- Created attachment 53562 --> https://bugs.freedesktop.org/attachment.cgi?id=53562 hand-typed "log"
While trying some self-made liveCD based on slackware-current, I found Slackware's Mesa works fine for both Celestia, and Q3 timedemo demo002. Slackware currently uses Mesa 7.10.2/libdrm 2.4.24/ and some nouveau DDX from march, 2011. I've compiled 7.11 branch , and discovered it hang videocard like 7.12 does on my main system. Then I just set good commit at last one from Luca. And even if i keep all other components the same (libdrm-2.4.27/xf86-video-nouveau few comments behind git/kernel 3.2.0-rc1 mainline) freeze go on and off with just mesa versions.My bisect compilation was without any llvm stuff (normal compilation has llvm 2.9). nice mistery, and thanfully whole machine not locked up hard, only videocard, it seems.
https://bugs.freedesktop.org/show_bug.cgi?id=34969
--- Comment #20 from Andrew Randrianasulu randrik@mail.ru 2012-04-14 14:53:55 PDT --- At least my hangs seems to be fixed by big driver rewrite. Currently using 3.4.0-rc2 nouveau kernel, libdrm up to commit 292da616fe1f936ca78a3fa8e1b1b19883e343b6 ("nouveau: pull in major libdrm rewrite"), mesa master up to commit b2df031a959f36743527b9abc89913ce4f895de3 ("r300/compiler: Fix nested flow control in r500 vertex shaders") and xf86-video-nouveau up to commit fb3a36b1e5af0f81bb266da894d3442eed8e4e55 ("nve0: initial exa/xv acceleration for kepler chipsets").
Please, re-test with new code.
https://bugs.freedesktop.org/show_bug.cgi?id=34969
Pierre Moreau pierre.morrow@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Component|DRM/other |Driver/nouveau Version|XOrg git |unspecified Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o |.org |rg Product|DRI |xorg QA Contact| |xorg-team@lists.x.org
--- Comment #21 from Pierre Moreau pierre.morrow@free.fr --- Moving to Nouveau.
Are you still experiencing this issue with an updated graphic stack, aka. kernel 3.18, mesa 10.4, libdrm 2.4.58 and f86-video-nouveau 1.0.11?
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org