Bug 28169 - [Gallium] state_tracker/st_mesa_to_tgsi.c:181: dst_register: Assertion `t->outputMapping[index] < (sizeof(t->outputs)/sizeof(*(t->outputs)))' failed
Summary: [Gallium] state_tracker/st_mesa_to_tgsi.c:181: dst_register: Assertion `t->ou...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium major
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-19 00:38 UTC by Fabio Pedretti
Modified: 2010-07-02 09:21 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
swrastg backtrace with ST_DEBUG=mesa,tgsi (23.19 KB, text/plain)
2010-05-19 00:38 UTC, Fabio Pedretti
Details
output showing "Mesa 7.9-devel implementation error: util_create_rgba_surface() failed in decompress_with_blit()" (5.50 KB, text/plain)
2010-05-19 02:51 UTC, Fabio Pedretti
Details
Additiona debug info with 0ad (1.09 KB, text/plain)
2010-07-01 08:58 UTC, Fabio Pedretti
Details
add num_draw_buffers to texenvprogram state key (2.32 KB, patch)
2010-07-01 09:27 UTC, Brian Paul
Details | Splinter Review
An additional debug assertion (471 bytes, patch)
2010-07-02 08:01 UTC, Brian Paul
Details | Splinter Review
Check number of draw buffers when emitting last texenv term (448 bytes, patch)
2010-07-02 09:04 UTC, Brian Paul
Details | Splinter Review

Description Fabio Pedretti 2010-05-19 00:38:28 UTC
Created attachment 35748 [details]
swrastg backtrace with ST_DEBUG=mesa,tgsi

[this is a follow-up of bug #27729]

The game 0ad crashes with the following assertion, tested on both swrastg and r300g with mesa up to 5a5a82d7:
pyrogenesis: state_tracker/st_mesa_to_tgsi.c:181: dst_register: Assertion `t->outputMapping[index] < (sizeof(t->outputs)/sizeof(*(t->outputs)))' failed.

Full console output + backtrace is attached.
Comment 1 Fabio Pedretti 2010-05-19 02:51:16 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.
Comment 2 Pavel Ondračka 2010-06-30 08:25:06 UTC
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 ?? ()
Comment 3 Brian Paul 2010-07-01 08:22:27 UTC
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)
Comment 4 Fabio Pedretti 2010-07-01 08:58:06 UTC
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.
Comment 5 Brian Paul 2010-07-01 09:27:23 UTC
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...
Comment 6 Fabio Pedretti 2010-07-01 23:56:29 UTC
(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
Comment 7 Brian Paul 2010-07-02 08:01:47 UTC
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.
Comment 8 Fabio Pedretti 2010-07-02 08:41:14 UTC
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.
Comment 9 Brian Paul 2010-07-02 09:04:47 UTC
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.
Comment 10 Fabio Pedretti 2010-07-02 09:12:59 UTC
(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).
Comment 11 Brian Paul 2010-07-02 09:21:37 UTC
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.