Bug 34974

Summary: Mesa demos regression since - tgsi: defer allocation of huge inputs/outputs until we have a gs
Product: Mesa Reporter: Andy Furniss <adf.lists>
Component: Mesa coreAssignee: Zack Rusin <zackr>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: brianp, jfonseca, monraaf
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Andy Furniss 2011-03-03 06:41:06 UTC
rv790, since

commit ff2a0faba068ac8bc891f4a6427ad3e241c5f09f
Author: Zack Rusin <zack@kde.org>
Date:   Tue Mar 1 22:50:42 2011 -0500

    tgsi: defer allocation of huge inputs/outputs until we have a gs

Using 600g demos that start with help text run but display no text.

drawpix,readpix and pixeltest fail to render.

With swrastg all tested segfault.

600c and swrast are unnaffected and render/run normally.

Testing with git ddx, libdrm and d-r-t. 1D tiling is enabled in xorg.conf.
Comment 1 Rafael Monica 2011-03-03 16:34:20 UTC
Seeing this also happening wit a bunch of piglit tests, both on r600g and softpipe.

e.g: 

stencil-drawpixels
scissor-copypixels
scissor-bitmap
Comment 2 Brian Paul 2011-03-03 16:51:32 UTC
What happens if you set GALLIUM_NOSSE=1?  I bet the tgsi->sse2 translator needs to be updated.
Comment 3 Rafael Monica 2011-03-03 17:18:59 UTC
Yeah, just did some quick tests and setting GALLIUM_NOSSE=1 does indeed seem to fix it.
Comment 4 Andy Furniss 2011-03-04 03:12:30 UTC
(In reply to comment #2)
> What happens if you set GALLIUM_NOSSE=1?  I bet the tgsi->sse2 translator needs
> to be updated.

I get a SIGTRAP on the demos which looks much the same with r600g and swrastg.

In case I am doing something lame/different here is my autogen -

./autogen.sh --prefix=/mypath --enable-debug --disable-egl --with-state-trackers=dri  --enable-gallium-r600 --enable-gallium-swrast --with-dri-drivers=r600,swrast
  

tgsi/tgsi_exec.c:1087:fetch_src_file_channel: Assertion `pos < (sizeof(mach->Inputs)/sizeof((mach->Inputs)[0]))' failed.

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0xb727f700 (LWP 1777)]
_debug_assert_fail (expr=0xb7212dac "pos < (sizeof(mach->Inputs)/sizeof((mach->Inputs)[0]))", file=0xb7212a63 "tgsi/tgsi_exec.c", line=1087, function=0xb721328f "fetch_src_file_channel") at util/u_debug.c:285
285     }
(gdb) bt
#0  _debug_assert_fail (expr=0xb7212dac "pos < (sizeof(mach->Inputs)/sizeof((mach->Inputs)[0]))", file=0xb7212a63 "tgsi/tgsi_exec.c", line=1087, function=0xb721328f "fetch_src_file_channel") at util/u_debug.c:285
#1  0xb70dca3f in fetch_src_file_channel (mach=0x933a7c0, file=<value optimized out>, swizzle=0, index=0xbfc3e32c, index2D=0xbfc3e31c, chan=0xbfc3e3b0) at tgsi/tgsi_exec.c:1087
#2  0xb70dd68f in fetch_source (mach=0x933a7c0, chan=0xbfc3e3b0, reg=0x9325a30, chan_index=0, src_datatype=TGSI_EXEC_DATA_FLOAT) at tgsi/tgsi_exec.c:1313
#3  0xb70dda08 in exec_vector_binary (mach=0x933a7c0, inst=0x9325a00, op=0xb70dbc20 <micro_mul>, dst_datatype=TGSI_EXEC_DATA_FLOAT, src_datatype=TGSI_EXEC_DATA_FLOAT) at tgsi/tgsi_exec.c:2317
#4  0xb70e239a in exec_instruction (mach=0x933a7c0, inst=0xbfc3fd41, pc=0xbfc3e9b8) at tgsi/tgsi_exec.c:3249
#5  0xb70e3fd3 in tgsi_exec_machine_run (mach=0x933a7c0) at tgsi/tgsi_exec.c:4036
#6  0xb70ce740 in vs_exec_run_linear (shader=0x9325460, input=0x9326910, output=0x93269e4, constants=0x93302d0, const_size=0x9330350, count=1, input_stride=68, output_stride=68) at draw/draw_vs_exec.c:148
#7  0xb70c6964 in fetch_pipeline_generic (middle=0x933a730, fetch_info=<value optimized out>, prim_info=0xbfc3eac8) at draw/draw_pt_fetch_shade_pipeline.c:189
#8  0xb70c6b39 in fetch_pipeline_linear_run (middle=0x933a730, start=0, count=1, prim_flags=0) at draw/draw_pt_fetch_shade_pipeline.c:345
#9  0xb70c954e in vsplit_segment_simple_linear (vsplit=0x9337cc0, flags=0, istart=0, icount=1) at draw/draw_pt_vsplit_tmp.h:229
#10 0xb70c9668 in vsplit_run_linear (frontend=0x9337cc0, start=0, count=1) at draw/draw_split_tmp.h:61
#11 0xb70c4f94 in draw_pt_arrays (draw=0x932fe38, prim=0, start=0, count=1) at draw/draw_pt.c:113
#12 0xb70c51e2 in draw_vbo (draw=0x932fe38, info=0xbfc3ec34) at draw/draw_pt.c:480
#13 0xb70c53fb in draw_arrays_instanced (draw=0x932fe38, mode=0, start=0, count=1, startInstance=0, instanceCount=1) at draw/draw_pt.c:408
#14 0xb70c5446 in draw_arrays (draw=0x932fe38, prim=0, start=0, count=1) at draw/draw_pt.c:376
#15 0xb708ebc9 in st_feedback_draw_vbo (ctx=0x92d6a88, arrays=0x93253c8, prims=0x9325448, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=1) at state_tracker/st_draw_feedback.c:251
#16 0xb7087da4 in st_RasterPos (ctx=0x92d6a88, v=0xbfc3f18c) at state_tracker/st_cb_rasterpos.c:254
#17 0xb6f80be6 in rasterpos (x=0, y=0, z=-1, w=1) at main/rastpos.c:65
#18 0xb6f81038 in _mesa_RasterPos3f (x=0, y=0, z=-1) at main/rastpos.c:102
#19 0x0804950a in Display () at drawpix.c:55
#20 0xb78200ea in processWindowWorkList (window=0x91ca6a0) at glut_event.c:1307
#21 0xb7820dea in glutMainLoop () at glut_event.c:1358
#22 0x08049351 in main (argc=1764699694, argv=Cannot access memory at address 0x8
) at drawpix.c:357
Comment 5 Jose Fonseca 2011-03-04 05:14:24 UTC
The assertion failure should have been fixed with

commit 9f3c59a35093c61fb11aab6d3ed5cb45f2b8c2a7
Author: José Fonseca <jfonseca@vmware.com>
Date:   Thu Mar 3 19:15:24 2011 +0000

    tgsi: Update assert.
    
    Elements(mach->Inputs) is wrong now that mach->Inputs is dynamically
    allocated.

I'm not sure why the segfaults..
Comment 6 Andy Furniss 2011-03-04 06:09:15 UTC
(In reply to comment #5)
> The assertion failure should have been fixed with
> 
> commit 9f3c59a35093c61fb11aab6d3ed5cb45f2b8c2a7
> Author: José Fonseca <jfonseca@vmware.com>
> Date:   Thu Mar 3 19:15:24 2011 +0000
> 
>     tgsi: Update assert.
> 
>     Elements(mach->Inputs) is wrong now that mach->Inputs is dynamically
>     allocated.
> 
> I'm not sure why the segfaults..

Yes, this does fix it with GALLIUM_NOSSE=1.

I hadn't updated mesa when I tested.

Without GALLIUM_NOSSE=1 the bug is still there.
Comment 7 Andy Furniss 2011-03-04 06:16:36 UTC
(In reply to comment #6)

> Without GALLIUM_NOSSE=1 the bug is still there.

This is tunnel with swrastg and current mesa using sse.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7237700 (LWP 7902)]
fs_sse_run (base=0x83fd650, machine=0x83590d0, quad=0x83a5910) at sp_fs_sse.c:164
164                    memcpy(quad->output.color[cbuf],
(gdb) bt
#0  fs_sse_run (base=0x83fd650, machine=0x83590d0, quad=0x83a5910) at sp_fs_sse.c:164
#1  0xb6ec3efb in shade_quads (qs=0x82ada68, quads=0x83a7cd0, nr=5) at sp_quad_fs.c:77
#2  0xb6ec7a6e in flush_spans (setup=0x83a58a8) at sp_setup.c:243
#3  0xb6ec8050 in subtriangle (setup=0x3f298a88, eleft=0x83a58ec, eright=0x83a58d4, lines=17) at sp_setup.c:751
#4  0xb6ec899c in sp_setup_tri (setup=0x83a58a8, v0=0x8473ce0, v1=0x8473ca0, v2=0x8473d20) at sp_setup.c:841
#5  0xb6ec0a10 in sp_vbuf_draw_arrays (vbr=0x82a3790, start=0, nr=12) at sp_prim_vbuf.c:427
#6  0xb70d9791 in draw_pt_emit_linear (emit=0x82a8730, vert_info=0xbf9b368c, prim_info=0xbf9b36c8) at draw/draw_pt_emit.c:265
#7  0xb707eacb in fetch_pipeline_generic (middle=0x82a8698, fetch_info=<value optimized out>, prim_info=0xbf9b36c8) at draw/draw_pt_fetch_shade_pipeline.c:168
#8  0xb707ec09 in fetch_pipeline_linear_run (middle=0x82a8698, start=12, count=12, prim_flags=0) at draw/draw_pt_fetch_shade_pipeline.c:345
#9  0xb708161e in vsplit_segment_simple_linear (vsplit=0x83740e8, flags=0, istart=12, icount=12) at draw/draw_pt_vsplit_tmp.h:229
#10 0xb7081738 in vsplit_run_linear (frontend=0x83740e8, start=12, count=12) at draw/draw_split_tmp.h:61
#11 0xb707d064 in draw_pt_arrays (draw=0x836dfe0, prim=5, start=12, count=12) at draw/draw_pt.c:113
#12 0xb707d2b2 in draw_vbo (draw=0x836dfe0, info=0xbf9b3ca4) at draw/draw_pt.c:480
#13 0xb6ebfe25 in softpipe_draw_vbo (pipe=0x82a18b8, info=0xbf9b3ca4) at sp_draw_arrays.c:143
#14 0xb6f6869b in st_draw_vbo (ctx=0x83aba88, arrays=0x83ee748, prims=0x83ed09c, nr_prims=5, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=59) at state_tracker/st_draw.c:741
#15 0xb70285a2 in vbo_exec_vtx_flush (exec=0x83ecf28, keepUnmapped=1 '\001') at vbo/vbo_exec_draw.c:389
#16 0xb701fa14 in vbo_exec_FlushVertices_internal (exec=0x83ecf28, unmap=136 '\210') at vbo/vbo_exec_api.c:543
#17 0xb70218c7 in vbo_exec_FlushVertices (ctx=0x83aba88, flags=1) at vbo/vbo_exec_api.c:990
#18 0xb6f50ea1 in _mesa_BindTexture (target=3553, texName=2) at main/texobj.c:1086
#19 0x0804a164 in draw () at tunnel.c:429
#20 0xb77d80ea in processWindowWorkList (window=0x829f6a0) at glut_event.c:1307
#21 0xb77d8dea in glutMainLoop () at glut_event.c:1358
#22 0x08049baa in main (ac=1, av=0xbf9b4144) at tunnel.c:540
Comment 8 Jose Fonseca 2011-03-04 07:03:29 UTC
I've commited a workaround:

commit 6838c9ce74f16c765474c0d2b4ae1469dd4a64d5
Author: José Fonseca <jfonseca@vmware.com>
Date:   Fri Mar 4 14:54:24 2011 +0000

    tgsi: Disable SSE2 code generation.
    
    It's broken now that tgsi_exec_machine::Inputs/Ouputs are pointers.
    
    Temporary if anybody still cares about tgsi_sse2.c. Permanent otherwise.


I think if people care about performance they should enable LLVM support.
Comment 9 Andy Furniss 2011-03-04 07:47:43 UTC
(In reply to comment #8)
> I've commited a workaround:
> 
> commit 6838c9ce74f16c765474c0d2b4ae1469dd4a64d5
> Author: José Fonseca <jfonseca@vmware.com>
> Date:   Fri Mar 4 14:54:24 2011 +0000
> 
>     tgsi: Disable SSE2 code generation.
> 
>     It's broken now that tgsi_exec_machine::Inputs/Ouputs are pointers.
> 
>     Temporary if anybody still cares about tgsi_sse2.c. Permanent otherwise.
> 
> 
> I think if people care about performance they should enable LLVM support.

Working, but I get a couple of these to stderr. 

draw/draw_vs_sse.c:203:draw_create_vs_sse: error: tgsi_emit_sse2() failed, falling back to interpreter
Comment 10 Jose Fonseca 2011-03-04 08:07:48 UTC
(In reply to comment #9)
> Working, but I get a couple of these to stderr. 
> 
> draw/draw_vs_sse.c:203:draw_create_vs_sse: error: tgsi_emit_sse2() failed,
> falling back to interpreter

It's not really error. It's really just a performance warning, and it should probably be silenced now that tgsi_emit_sse2 became a no-op.

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.