Summary: | [Gallium] state_tracker/st_mesa_to_tgsi.c:181: dst_register: Assertion `t->outputMapping[index] < (sizeof(t->outputs)/sizeof(*(t->outputs)))' failed | ||
---|---|---|---|
Product: | Mesa | Reporter: | Fabio Pedretti <pedretti.fabio> |
Component: | Mesa core | Assignee: | mesa-dev |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | major | ||
Priority: | medium | CC: | pavel.ondracka |
Version: | git | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
swrastg backtrace with ST_DEBUG=mesa,tgsi
output showing "Mesa 7.9-devel implementation error: util_create_rgba_surface() failed in decompress_with_blit()" Additiona debug info with 0ad add num_draw_buffers to texenvprogram state key An additional debug assertion Check number of draw buffers when emitting last texenv term |
Description
Fabio Pedretti
2010-05-19 00:38:28 UTC
Created attachment 35753 [details]
output showing "Mesa 7.9-devel implementation error: util_create_rgba_surface() failed in decompress_with_blit()"
One time I was able to run the game for a few seconds, but it showed:
Mesa 7.9-devel implementation error: util_create_rgba_surface() failed in decompress_with_blit()
and then crashed in the same way. This output is also attached.
Probably the same problem with Scorched 3D with normal settings. http://sourceforge.net/projects/scorched3d/files/scorched3d/Version%2043.1c Difference between normal and faster settings (crashing and stable) is usage of GL shaders. #0 0x00f00416 in __kernel_vsyscall () #1 0x009b5d31 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x009b760a in abort () at abort.c:92 #3 0x009aeda8 in __assert_fail ( assertion=0x11e290c "t->outputMapping[index] < (sizeof(t->outputs)/sizeof(*(t->outputs)))", file=0x11e2884 "state_tracker/st_mesa_to_tgsi.c", line=181, function=0x11e2e67 "dst_register") at assert.c:81 #4 0x010e75b7 in dst_register (t=0xbfffdc94, file=PROGRAM_OUTPUT, index=1) at state_tracker/st_mesa_to_tgsi.c:181 #5 0x010e7afe in translate_dst (t=0xbfffdc94, DstReg=0xc9dd68c, saturate=0 '\000') at state_tracker/st_mesa_to_tgsi.c:284 #6 0x010e8b5a in compile_instruction (t=0xbfffdc94, inst=0xc9dd670) at state_tracker/st_mesa_to_tgsi.c:640 #7 0x010ea33a in st_translate_mesa_program (ctx=0xb80d9a0, procType=0, ureg=0xc9f3bb0, program=0xc9eadd0, numInputs=0, inputMapping=0xbfffed94, inputSemanticName=0xbfffed44 "\250\355\377\277\002", inputSemanticIndex=0xbfffed34 "\003", interpMode=0xbfffed54, numOutputs=0, outputMapping=0xbfffee0c, outputSemanticName=0xbfffed24 "6", outputSemanticIndex=0xbfffed14 "", passthrough_edgeflags=0 '\000') at state_tracker/st_mesa_to_tgsi.c:1098 #8 0x010eb2f8 in st_translate_fragment_program (st=0xb84cd58, stfp=0xc9eadd0) at state_tracker/st_program.c:436 #9 0x010d0bd4 in translate_fp (st=0xb84cd58, stfp=0xc9eadd0) at state_tracker/st_atom_shader.c:65 #10 0x010d0e67 in update_fp (st=0xb84cd58) at state_tracker/st_atom_shader.c:176 #11 0x010cbf3a in st_validate_state (st=0xb84cd58) at state_tracker/st_atom.c:172 #12 0x010d7fbd in st_Clear (ctx=0xb80d9a0, mask=16) at state_tracker/st_cb_clear.c:463 #13 0x00f7370b in _mesa_Clear (mask=256) at main/clear.c:178 #14 0x0750ae6d in glClear (mask=256) at ../../src/mesa/glapi/glapitemp.h:1102 #15 0x082648cd in ?? () #16 0x08189ffc in ?? () #17 0x0818a072 in ?? () #18 0x08259080 in ?? () #19 0x080bfb7b in ?? () #20 0x080c2dd6 in ?? () #21 0x0817bf4e in ?? () #22 0x0832b120 in ?? () #23 0x009a1cc6 in __libc_start_main (main=0x832af60, argc=3, ubp_av=0xbffff354, init=0x832b310, fini=0x832b300, rtld_fini=0x978220 <_dl_fini>, stack_end=0xbffff34c) at libc-start.c:226 #24 0x0804e8b1 in ?? () Can you provide some additional debug info? After hitting the assertion, go up the stack into st_translate_mesa_program() and do the following in gdb: (gdb) call _mesa_print_program(program) and (gdb) call _mesa_print_program_parameters(ctx, program) Created attachment 36660 [details] Additiona debug info with 0ad (In reply to comment #3) > Can you provide some additional debug info? After hitting the assertion, go up > the stack into st_translate_mesa_program() and do the following in gdb: > > (gdb) call _mesa_print_program(program) > > and > > (gdb) call _mesa_print_program_parameters(ctx, program) Output is attached with the 0ad game. Created attachment 36661 [details] [review] add num_draw_buffers to texenvprogram state key Can you try this patch? The problem is the program->OutputsWritten field is 0 when the program clearly writes to OUTPUT[1]. AFAICT, this may be coming from a bug in the texenvprogram generation code. On the other hand, if GLSL shaders are being used, perhaps the problem is elsewhere... (In reply to comment #5) > Created an attachment (id=36661) [details] > add num_draw_buffers to texenvprogram state key > > Can you try this patch? > > The problem is the program->OutputsWritten field is 0 when the program clearly > writes to OUTPUT[1]. AFAICT, this may be coming from a bug in the > texenvprogram generation code. On the other hand, if GLSL shaders are being > used, perhaps the problem is elsewhere... It's still crashing in the same way, but now also print some: Warning: CONST[0]: Register never used 0 errors, 1 warnings Warning: IN[0]: Register never used 0 errors, 1 warnings Created attachment 36689 [details] [review] An additional debug assertion Here's another patch to try to debug this. If gdb fails on this new assertion, it'll help explain things. I updated up to 291bcfd8 and applied the patch. Now it asserts with: pyrogenesis: main/texenvprogram.c:491: make_state_key: Assertion `key->num_draw_buffers > 0' failed. Created attachment 36690 [details] [review] Check number of draw buffers when emitting last texenv term OK, I reproduced the bug here with a test program. The attached patch fixes it here for me. This should be applied to the latest Mesa code from git. (In reply to comment #9) > Created an attachment (id=36690) [details] > Check number of draw buffers when emitting last texenv term > > OK, I reproduced the bug here with a test program. The attached patch fixes it > here for me. This should be applied to the latest Mesa code from git. Yes, the game starts fine now, thanks. It also works visually fine with swrastg, but with r300g + libtxc_dxtn.so all textures are blueish (bug #28437). OK, patch committed as 6e83420ee0ccb2228fab0f86a6e8bf8a6aefe57a. I'm closing this bug. The r300g blue texture issue should be filed as another bug. |
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.