Bug 30616 - r600g glitching in tunnel demo
Summary: r600g glitching in tunnel demo
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-05 02:40 UTC by Andy Furniss
Modified: 2011-01-30 11:57 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg (41.99 KB, text/plain)
2010-12-04 04:40 UTC, Andy Furniss
Details

Description Andy Furniss 2010-10-05 02:40:27 UTC
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.
Comment 1 Andy Furniss 2010-10-12 03:14:10 UTC
(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).
Comment 2 Andy Furniss 2010-10-17 03:14:43 UTC
(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.
Comment 3 Andy Furniss 2010-12-04 04:06:07 UTC
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.
Comment 4 Andy Furniss 2010-12-04 04:40:52 UTC
Created attachment 40799 [details]
dmesg
Comment 5 Andy Furniss 2010-12-07 05:39:59 UTC
(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
Comment 6 Andy Furniss 2010-12-10 03:27:33 UTC
(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.
Comment 7 Andy Furniss 2010-12-10 05:01:01 UTC
(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.
Comment 8 Jerome Glisse 2010-12-10 07:40:19 UTC
the assert should give a bigger message, like a trace please paste it here
Comment 9 Andy Furniss 2010-12-10 10:05:10 UTC
(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.
Comment 10 Andy Furniss 2010-12-10 11:26:49 UTC
(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 ?? ()
Comment 11 Andy Furniss 2010-12-15 12:44:25 UTC
(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
Comment 12 Andy Furniss 2010-12-15 13:14:06 UTC
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.
Comment 13 Andy Furniss 2011-01-30 11:57:54 UTC
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.