Nicolai Haehnle wrote:
> On 3/27/07, Brian Paul <[EMAIL PROTECTED]> wrote:
>> Keith Whitwell wrote:
>>> This is not the first time someone has tried to remove that field. Dont!
>>> Just because it isn't used in core mesa doesn't mean the drivers don't rely
>>> on it...
>>>
>>> Yes, it's ugly, but it is currently neccessary.
>> Sorry, Keith.
>>
>> I made a bunch of changes to the ctx->FragmentProgram._Current,
>> _Enabled, _Active, etc. field usage in light of the shading language
>> work. I know the drivers use _UseTexEnvProgram but, like I said, I
>> believed an overhaul in the logic took away the need for it.
>>
>> Unfortunately, my i915 system is still out of order. I _think_ things
>> will work again now but I know there are still some additional issues
>> with the _Current/_Active fields that'll I'll have to get back to someday.
>>
>> Nicolai, can you retest the R300 w/ glean?
>
> Sorry for taking so long with this, but real life reared its ugly
> head. In any case, I can confirm that texEnv and texCombine work
> correctly again on R300.
>
> pixelFormat and texgen are still broken, I'm looking into that.
>
I have found another regression caused by the glsl-compiler-1 merge.
Quake3 looks horrible on R300. When you look at the vertex/fragment
program difference. (oh and a ';' is missing after END =)
good is before merge, bad is after:
--- r300_good.txt 2007-04-02 19:44:50.000000000 +0200
+++ r300_bad.txt 2007-04-02 19:44:03.000000000 +0200
@@ -1,12 +1,13 @@
Mesa program:
-------------
- 0: TXP TEMP[0], INPUT[4], texture[0], 2D
- 1: TXP TEMP[1], INPUT[5], texture[1], 2D
- 2: MUL_SAT TEMP[2].xyz, TEMP[0], INPUT[1];
- 3: MOV_SAT TEMP[2].w, INPUT[1];
- 4: MUL OUTPUT[0].xyz, TEMP[1], TEMP[2];
- 5: MOV OUTPUT[0].w, TEMP[2];
- 6: END;
+# Fragment Program/Shader
+ 0: TXP TEMP[0] (cond???..xxxx), INPUT[4], texture[0], 2D;
+ 1: TXP TEMP[1] (cond???..xxxx), INPUT[5], texture[1], 2D;
+ 2: MUL_SAT TEMP[2].xyz (cond???..xxxx), TEMP[0], INPUT[1];
+ 3: MOV_SAT TEMP[2].w (cond???..xxxx), INPUT[1];
+ 4: MUL OUTPUT[0].xyz (cond???..xxxx), TEMP[1], TEMP[2];
+ 5: MOV OUTPUT[0].w (cond???..xxxx), TEMP[2];
+ 6: END
Hardware program
----------------
NODE 0: alu_offset: 0, tex_offset: 0, alu_end: 1, tex_end: 1
@@ -22,11 +23,11 @@
xyz: t4.xyz t5.xyz 0.0 op: 00050200
w: t5.w 1.0 0.0 op: 00040889
vertex prog:
+# Vertex Program/Shader
0: MUL TEMP[0], INPUT[0].xxxx, STATE[0];
1: MAD TEMP[0], INPUT[0].yyyy, STATE[1], TEMP[0];
2: MAD TEMP[0], INPUT[0].zzzz, STATE[2], TEMP[0];
3: MAD OUTPUT[0], INPUT[0].wwww, STATE[3], TEMP[0];
4: MOV OUTPUT[1], INPUT[3];
5: MOV OUTPUT[4], INPUT[8];
- 6: MOV OUTPUT[5], INPUT[9];
- 7: END;
+ 6: END
Rune Petersen
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
