Bug 30616

(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).

(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.

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.

Created attachment 40799 [details]
dmesg

(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

(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.

(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.

the assert should give a bigger message, like a trace please paste it here

(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.

(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 ?? ()

(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

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.

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.