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 core | Assignee: | 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
Seeing this also happening wit a bunch of piglit tests, both on r600g and softpipe. e.g: stencil-drawpixels scissor-copypixels scissor-bitmap What happens if you set GALLIUM_NOSSE=1? I bet the tgsi->sse2 translator needs to be updated. Yeah, just did some quick tests and setting GALLIUM_NOSSE=1 does indeed seem to fix it. (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 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.. (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. (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 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. (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 (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.