Bug 5459

Created attachment 4198 [details]
Test program

Both cases fail on rv350

I'm not able to test this myself on r300 hardware currently.  How does the test
case fail? ie. complete blackness, or just the wrong image?

Also, are you able to turn on the dump_program() call at the end of
translate_fragment_shader() and post the output please?

(In reply to comment #2)
> I'm not able to test this myself on r300 hardware currently.  How does the test
> case fail? ie. complete blackness, or just the wrong image?

First one was black and second darkish.
However, I tested this again on r480 and got different results.
Some more testing reveals that sometimes it works and sometimes not.
Im suspecting undefined z or w component is leaking into to the tex instruction,
thus causing random behaviour.

> 
> Also, are you able to turn on the dump_program() call at the end of
> translate_fragment_shader() and post the output please?

I have been able to reproduce this with another program:
"!!ARBfp1.0\n"
"ATTRIB i0 = fragment.color;"
"TEMP t0, t1;"
"MOV t0, i0;"
"TEX result.color, t0, texture[0], 2D;"
"END"

I either get zero visible fragments with this or then it works as expected.

output:

pc=1*************************************
Mesa program:
-------------
  0: MOV TEMP[0], INPUT[1];
  1: TEX  OUTPUT[0], TEMP[0], texture[0], 2D
  2: END;
Hardware program
----------------

tex:
00008081

NODE 0: alu_offset: 0, tex_offset: 0, alu_end: 0, tex_end: -1
NODE 1: alu_offset: 1, tex_offset: 0, alu_end: 1, tex_end: 0
00011230
00050a80
00050a80
000111b0
03860800
1c020802
00011270
00040889
00040889
000111f0
00860800
01020802
00000000

Okay, the disassembly of the fragment program doesn't turn up any obvious
mistakes in the program generation.

I'll try and convince Xorg to play nice with radeon again on Sunday and take a
closer look.

Okay, the issue doesn't occur once I port the changes from r300.sf.net cvs over
to mesa cvs head.  What I believe is happening is that the nodes which control
texture indirection are being setup incorrectly.  alu_end and tex_end are
actually relative to alu_offset and tex_offset, not to the start of the program.
 This is one of the things that "fixes for some badness on my behalf" is
referring to in the commit message.

I've ported the code from r300 cvs over to current Mesa cvs head.  Would you
prefer to look that over and commit it, or would you like me to fix this
particular issue seperately?

(In reply to comment #5)
> Okay, the issue doesn't occur once I port the changes from r300.sf.net cvs over
> to mesa cvs head.  What I believe is happening is that the nodes which control
> texture indirection are being setup incorrectly.  alu_end and tex_end are
> actually relative to alu_offset and tex_offset, not to the start of the program.
>  This is one of the things that "fixes for some badness on my behalf" is
> referring to in the commit message.
> 
> I've ported the code from r300 cvs over to current Mesa cvs head.  Would you
> prefer to look that over and commit it, or would you like me to fix this
> particular issue seperately?

One set of changes will be just fine.

Created attachment 4302 [details] [review]
fix node setup

Here it is, not tested against anything except a few mesa demos and your test
program.

(In reply to comment #7)
> Created an attachment (id=4302) [edit]
> fix node setup
> 
> Here it is, not tested against anything except a few mesa demos and your test
> program.

Commited. That didnt fix q4 though.
Do you have the other patch around so I can check it in?

Created attachment 4304 [details] [review]
Missing code from r300.sf.net cvs

Okay.  There's quite a few changes in there, I don't recall it breaking
anything but I can't be sure.

Doom3 seemed to look almost fine (once disabling S3TC) so hopefully Quake4 will
also.  I couldn't test quake4 as it was SEGV'ing somewhere after
tnl/t_vb_arbprogram_sse.c::build_vertex_program().

That patch makes some static functions non-static, without adding the "r300"
prefix to the function name. Doesn't seem like a good idea?

(In reply to comment #9)
> Created an attachment (id=4304) [edit]
> Missing code from r300.sf.net cvs
> 
> Okay.  There's quite a few changes in there, I don't recall it breaking
> anything but I can't be sure.

Thanks.
Iv checked it in.

> 
> Doom3 seemed to look almost fine (once disabling S3TC) so hopefully Quake4 will
> also.  I couldn't test quake4 as it was SEGV'ing somewhere after
> tnl/t_vb_arbprogram_sse.c::build_vertex_program().

q4 worked for me when sse codegen was turned off. Ill see if I can get it to
work with hw vertex shaders.