https://bugs.freedesktop.org/show_bug.cgi?id=30616
Summary: r600g glitching in tunnel demo Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: lists@andyfurniss.entadsl.com
Running xserver 1.9,gits ddx/mesa/libdrm and d-r-t on rv790 with wait vline/dri2 vsync disabled.
Since the mesa commit 3d45d57044507506ca834a4bf983422549c5240a r600g: TODO domain management
I get quite severe 1/2 second glitches running the mesa demo tunnel, it seems that rather than a regression this commit causes an amplification of a pre existing, but low level issue.
The glitches do not show in most games, sauerbraten will show it.
They are worse if I have my card set to high perf.
Running latencytop + tunnel often shows nothing, but will sometimes catch a 1/2 second event in radeon_fence_wait, and more rarely 300ms in radeon_cs_ioctl.
r600c does not glitch.
https://bugs.freedesktop.org/show_bug.cgi?id=30616
--- Comment #1 from Andy Furniss lists@andyfurniss.entadsl.com 2010-10-12 03:14:10 PDT --- (In reply to comment #0)
I get quite severe 1/2 second glitches running the mesa demo tunnel
Still getting this, just wanted to add that it seems to be related to demos that start with help text. Tunnel, teapot and terrain will all glitch really badly when I start then with my card set to high. Pressing h to remove the text will alleviate the problem, though I will still get another glitch after some time (say 30 secs).
https://bugs.freedesktop.org/show_bug.cgi?id=30616
--- Comment #2 from Andy Furniss lists@andyfurniss.entadsl.com 2010-10-17 03:14:43 PDT --- (In reply to comment #0)
They are worse if I have my card set to high perf.
It seems that it's not just the card being set to full speed that affects things. The script I use to set the card to full also sets cpufreq from ondemand to performance.
If I set card to full and leave cpufreq ondemand then tunnel will not cause cpu to go above 800MHz (max is 3.4Ghz) and the glitching will not be instantly noticeable.
I also tested with all four possible vsync settings and they all glitch.
https://bugs.freedesktop.org/show_bug.cgi?id=30616
--- Comment #3 from Andy Furniss lists@andyfurniss.entadsl.com 2010-12-04 04:06:07 PST --- Haven't been able to test this for a while as this box had a mobo failiure.
Current situation with git d-r-t, ddx and mesa -
With CPU and card set high mesa demos with help screen still glitch when the text is displayed but only if writeback is enabled.
no_wb=1 seems to fix all glitching in demos, but it doesn't fix sauerbraten, which currently locks up the GPU eventually (monitor off, no GPU reset, nothing logged SysRq still works).
Sauerbraten runs OK (I am testing fullscreen) if wait for vline is enabled in ddx so the framerate is capped.
https://bugs.freedesktop.org/show_bug.cgi?id=30616
--- Comment #4 from Andy Furniss lists@andyfurniss.entadsl.com 2010-12-04 04:40:52 PST --- Created an attachment (id=40799) --> (https://bugs.freedesktop.org/attachment.cgi?id=40799) dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=30616
--- Comment #5 from Andy Furniss lists@andyfurniss.entadsl.com 2010-12-07 05:39:59 PST --- (In reply to comment #3)
Haven't been able to test this for a while as this box had a mobo failiure.
Current situation with git d-r-t, ddx and mesa -
With CPU and card set high mesa demos with help screen still glitch when the text is displayed but only if writeback is enabled.
no_wb=1 seems to fix all glitching in demos, but it doesn't fix sauerbraten, which currently locks up the GPU eventually (monitor off, no GPU reset, nothing logged SysRq still works).
Sauerbraten runs OK (I am testing fullscreen) if wait for vline is enabled in ddx so the framerate is capped.
The Sauerbraten lock up is fixed by -
commit fa86fc564aea4e40c89f6fc889e6a5bf817634b3 Author: Jerome Glisse jglisse@redhat.com Date: Fri Dec 3 20:47:02 2010 -0500
r600g: build fetch shader from vertex elements
The game caps it's own fps to 200, so perhaps if it was a many vertices thing then the commit avoids rather than fixes.
The mesa demos + full speed + text + writeback issue persists and I have possibly found another way to illustrate it.
The mesa demo perf/copytex shows the issue with poor glCopyTexImage(64 x 64).
Writeback enabled card and CPU full speed -
glCopyTexImage(16 x 16): 4171.1 copies/sec, 4.1 Mpixels/sec glCopyTexImage(64 x 64): 6.3 copies/sec, 0.1 Mpixels/sec glCopyTexImage(256 x 256): 2762.0 copies/sec, 690.5 Mpixels/sec glCopyTexImage(1024 x 1024): 260.6 copies/sec, 1042.2 Mpixels/sec glCopyTexImage(4096 x 4096): 17.9 copies/sec, 1145.7 Mpixels/sec glCopyTexSubImage(16 x 16): 10138.6 copies/sec, 9.9 Mpixels/sec glCopyTexSubImage(64 x 64): 13642.0 copies/sec, 213.2 Mpixels/sec glCopyTexSubImage(256 x 256): 8410.7 copies/sec, 2102.7 Mpixels/sec glCopyTexSubImage(1024 x 1024): 1224.9 copies/sec, 4899.5 Mpixels/sec glCopyTexSubImage(4096 x 4096): 97.6 copies/sec, 6248.7 Mpixels/sec
Writeback enabled card and CPU low speed
glCopyTexImage(16 x 16): 2385.7 copies/sec, 2.3 Mpixels/sec glCopyTexImage(64 x 64): 2132.2 copies/sec, 33.3 Mpixels/sec glCopyTexImage(256 x 256): 691.9 copies/sec, 173.0 Mpixels/sec glCopyTexImage(1024 x 1024): 89.7 copies/sec, 358.7 Mpixels/sec glCopyTexImage(4096 x 4096): 10.8 copies/sec, 690.3 Mpixels/sec glCopyTexSubImage(16 x 16): 4183.9 copies/sec, 4.1 Mpixels/sec glCopyTexSubImage(64 x 64): 4039.4 copies/sec, 63.1 Mpixels/sec glCopyTexSubImage(256 x 256): 2762.0 copies/sec, 690.5 Mpixels/sec glCopyTexSubImage(1024 x 1024): 400.6 copies/sec, 1602.5 Mpixels/sec glCopyTexSubImage(4096 x 4096): 28.9 copies/sec, 1851.7 Mpixels/sec
Writeback disabled card and CPU full speed -
glCopyTexImage(16 x 16): 8302.7 copies/sec, 8.1 Mpixels/sec glCopyTexImage(64 x 64): 6989.8 copies/sec, 109.2 Mpixels/sec glCopyTexImage(256 x 256): 2694.7 copies/sec, 673.7 Mpixels/sec glCopyTexImage(1024 x 1024): 261.4 copies/sec, 1045.4 Mpixels/sec glCopyTexImage(4096 x 4096): 17.6 copies/sec, 1123.7 Mpixels/sec glCopyTexSubImage(16 x 16): 14371.9 copies/sec, 14.0 Mpixels/sec glCopyTexSubImage(64 x 64): 13473.7 copies/sec, 210.5 Mpixels/sec glCopyTexSubImage(256 x 256): 8432.3 copies/sec, 2108.1 Mpixels/sec glCopyTexSubImage(1024 x 1024): 1233.0 copies/sec, 4932.0 Mpixels/sec glCopyTexSubImage(4096 x 4096): 90.6 copies/sec, 5797.6 Mpixels/sec
Writeback disabled card and CPU low speed -
glCopyTexImage(16 x 16): 4457.7 copies/sec, 4.4 Mpixels/sec glCopyTexImage(64 x 64): 2134.4 copies/sec, 33.4 Mpixels/sec glCopyTexImage(256 x 256): 1043.4 copies/sec, 260.9 Mpixels/sec glCopyTexImage(1024 x 1024): 120.3 copies/sec, 481.2 Mpixels/sec glCopyTexImage(4096 x 4096): 10.6 copies/sec, 679.5 Mpixels/sec glCopyTexSubImage(16 x 16): 4177.5 copies/sec, 4.1 Mpixels/sec glCopyTexSubImage(64 x 64): 4055.4 copies/sec, 63.4 Mpixels/sec glCopyTexSubImage(256 x 256): 2771.3 copies/sec, 692.8 Mpixels/sec glCopyTexSubImage(1024 x 1024): 400.6 copies/sec, 1602.5 Mpixels/sec glCopyTexSubImage(4096 x 4096): 28.9 copies/sec, 1851.7 Mpixels/sec
https://bugs.freedesktop.org/show_bug.cgi?id=30616
--- Comment #6 from Andy Furniss lists@andyfurniss.entadsl.com 2010-12-10 03:27:33 PST --- (In reply to comment #0)
Since -
7055068eeae7f64166cca513282829d5a3e9b9d3 r600g: specialized upload manager
I have another test case for high vs low perf.
Nexuiz timedemo demos/demo1 with card/cpu high will after a second -
../../../../../src/gallium/auxiliary/util/u_inlines.h:81:pipe_reference_described: Assertion `pipe_is_referenced(reference)' failed.
This does not happen with perf low.
https://bugs.freedesktop.org/show_bug.cgi?id=30616
--- Comment #7 from Andy Furniss lists@andyfurniss.entadsl.com 2010-12-10 05:01:01 PST --- (In reply to comment #6)
Nexuiz timedemo demos/demo1 with card/cpu high will after a second -
../../../../../src/gallium/auxiliary/util/u_inlines.h:81:pipe_reference_described: Assertion `pipe_is_referenced(reference)' failed.
This does not happen with perf low.
Further testing shows that this is unaffected by writeback setting - happens with 0 or 1.
https://bugs.freedesktop.org/show_bug.cgi?id=30616
--- Comment #8 from Jerome Glisse glisse@freedesktop.org 2010-12-10 07:40:19 PST --- the assert should give a bigger message, like a trace please paste it here
https://bugs.freedesktop.org/show_bug.cgi?id=30616
--- Comment #9 from Andy Furniss lists@andyfurniss.entadsl.com 2010-12-10 10:05:10 PST --- (In reply to comment #8)
the assert should give a bigger message, like a trace please paste it here
It doesn't give a trace - running the binary direct just gives
Trace/breakpoint trap
I've tried gdb but it doesn't assert when running under it.
https://bugs.freedesktop.org/show_bug.cgi?id=30616
--- Comment #10 from Andy Furniss lists@andyfurniss.entadsl.com 2010-12-10 11:26:49 PST --- (In reply to comment #9)
I've tried gdb but it doesn't assert when running under it.
Sauerbraten is also affected, whatever perf is set to. It also works with gdb -
../../../../../src/gallium/auxiliary/util/u_inlines.h:81:pipe_reference_described: Assertion `pipe_is_referenced(reference)' failed.
Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 0xb72746d0 (LWP 7870)] _debug_assert_fail (expr=0xb65b2b3f "pipe_is_referenced(reference)", file=0xb65b4fec "../../../../../src/gallium/auxiliary/util/u_inlines.h", line=81, function=0xb65b9555 "pipe_reference_described") at util/u_debug.c:237 237 } (gdb) bt #0 _debug_assert_fail (expr=0xb65b2b3f "pipe_is_referenced(reference)", file=0xb65b4fec "../../../../../src/gallium/auxiliary/util/u_inlines.h", line=81, function=0xb65b9555 "pipe_reference_described") at util/u_debug.c:237 #1 0xb63a533a in r600_bo_reference (radeon=0x8823678, dst=0x8b13dec, src=0xe47de78) at ../../../../../src/gallium/auxiliary/util/u_inlines.h:81 #2 0xb63a8570 in r600_context_pipe_state_set_fs_resource (ctx=0x8838ad0, state=0xb62bb810, rid=1) at r600_hw_context.c:878 #3 0xb63853b1 in r600_vertex_buffer_update (rctx=0x8838948) at r600_state.c:201 #4 0xb63965ef in r600_bind_vertex_elements (ctx=0x8838948, state=0x8b3f118) at r600_state_common.c:129 #5 0xb656da57 in util_blitter_clear (blitter=0x8b3aad8, width=1024, height=768, num_cbufs=1, clear_buffers=<value optimized out>, rgba=0x8b4551c, depth=1, stencil=0) at util/u_blitter.c:693 #6 0xb6399773 in r600_clear (ctx=0x8838948, buffers=1, rgba=0x8b4551c, depth=1, stencil=0) at r600_blit.c:122 #7 0xb6506368 in st_Clear (ctx=0x8b44810, mask=2) at state_tracker/st_cb_clear.c:550 #8 0xb64bc65a in _mesa_Clear (mask=16384) at main/clear.c:241 #9 0x08082abe in ?? () #10 0x0815f7be in ?? () #11 0x0818fdfd in ?? () #12 0x08194bf3 in ?? () #13 0x0805c49e in ?? () #14 0x0812d1bc in ?? () #15 0x0812dafd in ?? () #16 0x0819a333 in ?? () #17 0x0812e116 in ?? () #18 0x0805ca6a in ?? () #19 0x0818b2c5 in ?? () #20 0x0808486a in ?? () #21 0xb73ef380 in __libc_start_main () from /lib/libc.so.6 #22 0x0804c791 in ?? ()
https://bugs.freedesktop.org/show_bug.cgi?id=30616
--- Comment #11 from Andy Furniss lists@andyfurniss.entadsl.com 2010-12-15 12:44:25 PST --- (In reply to comment #10)
../../../../../src/gallium/auxiliary/util/u_inlines.h:81:pipe_reference_described: Assertion `pipe_is_referenced(reference)' failed.
Fixed in master now, by (I guess) r600g: need to reference upload buffer as the might still live accross flush
https://bugs.freedesktop.org/show_bug.cgi?id=30616
Jerome Glisse glisse@freedesktop.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=30616
Andy Furniss lists@andyfurniss.entadsl.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |
--- Comment #12 from Andy Furniss lists@andyfurniss.entadsl.com 2010-12-15 13:14:06 PST --- The tunnel glitching with high perf + text is not fixed.
The assert I should have been filed as a separate bug - just when I first saw it it depended on perf settings like this one, but turned out to be unrelated.
https://bugs.freedesktop.org/show_bug.cgi?id=30616
Andy Furniss lists@andyfurniss.entadsl.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED
--- Comment #13 from Andy Furniss lists@andyfurniss.entadsl.com 2011-01-30 11:57:54 PST --- Tunnel glitching with card/cpu set to high perf when help text displayed is fixed by -
commit 2a456dc123e8263de8e4666890a34f403faa9a39 Author: Marek Olšák maraeo@gmail.com Date: Sat Jan 29 05:11:01 2011 +0100
u_blitter: use user buffers instead of real buffers
User buffers may be the fastest way to upload data.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org