Bug 5459 - Quake 4 darkness
Quake 4 darkness
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300
unspecified
x86 (IA32) Linux (All)
: high normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-30 17:57 UTC by Aapo Tahkola
Modified: 2006-01-09 15:05 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Test program (3.11 KB, application/octet-stream)
2005-12-30 18:01 UTC, Aapo Tahkola
Details
fix node setup (681 bytes, patch)
2006-01-10 03:25 UTC, Ben Skeggs
Details | Splinter Review
Missing code from r300.sf.net cvs (55.60 KB, patch)
2006-01-10 07:48 UTC, Ben Skeggs
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Aapo Tahkola 2005-12-30 17:57:31 UTC
Tested with experimental bits on as usual.
Comment 1 Aapo Tahkola 2005-12-30 18:01:24 UTC
Created attachment 4198 [details]
Test program

Both cases fail on rv350
Comment 2 Ben Skeggs 2006-01-05 21:00:15 UTC
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?
Comment 3 Aapo Tahkola 2006-01-06 18:49:08 UTC
(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
Comment 4 Ben Skeggs 2006-01-07 05:04:02 UTC
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.
Comment 5 Ben Skeggs 2006-01-10 01:13:40 UTC
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?
Comment 6 Aapo Tahkola 2006-01-10 02:52:02 UTC
(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.
Comment 7 Ben Skeggs 2006-01-10 03:25:38 UTC
Created attachment 4302 [details] [review]
fix node setup

Here it is, not tested against anything except a few mesa demos and your test
program.
Comment 8 Aapo Tahkola 2006-01-10 05:41:40 UTC
(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?
Comment 9 Ben Skeggs 2006-01-10 07:48:07 UTC
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().
Comment 10 Tilman Sauerbeck 2006-01-10 08:21:48 UTC
That patch makes some static functions non-static, without adding the "r300"
prefix to the function name. Doesn't seem like a good idea?
Comment 11 Aapo Tahkola 2006-01-10 10:05:30 UTC
(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.