diff -ru trunk_20030619/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_tcl.c tex3_20030619/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_tcl.c --- trunk_20030619/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_tcl.c Fri May 2 13:01:54 2003 +++ tex3_20030619/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_tcl.c Thu Jun 19 14:02:42 2003 @@ -385,6 +385,16 @@ } }
+ if (ctx->Texture.Unit[2]._ReallyEnabled) { + if (ctx->Texture.Unit[2].TexGenEnabled) { + if (rmesa->TexGenNeedNormals[2]) { + inputs |= VERT_BIT_NORMAL; + } + } else { + inputs |= VERT_BIT_TEX2; + } + } +
I don't remember, but could this be made into a loop?
you are right, yes, maybe. but I thought it isnt a problem for 3TMUs, only for 6 (r200) ;) so it could be good to have it here, too.
One of my goals in the original texmem work was to minimize the textual diffs between the radeon and r200 drivers. At some point after all driver work gets moved to the Mesa tree, we should look at making a radeon_common directory that contains code shared by those two drivers. I think the time for doing that is still a ways off, but it's something to keep in mind.
diff -ru trunk_20030619/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_vtxfmt_sse.c tex3_20030619/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_vtxfmt_sse.c --- trunk_20030619/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_vtxfmt_sse.c Fri May 2 13:01:56 2003 +++ tex3_20030619/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_vtxfmt_sse.c Thu Jun 26 18:58:10 2003 @@ -178,13 +178,21 @@ if (RADEON_DEBUG & DEBUG_CODEGEN) fprintf(stderr, "%s 0x%08x\n", __FUNCTION__, key );
- if ((key & (RADEON_CP_VC_FRMT_ST0|RADEON_CP_VC_FRMT_ST1)) == - (RADEON_CP_VC_FRMT_ST0|RADEON_CP_VC_FRMT_ST1)) { - DFN ( _sse_MultiTexCoord2fv, rmesa->vb.dfn_cache.MultiTexCoord2fvARB ); - FIXUP(dfn->code, 18, 0xdeadbeef, (int)rmesa->vb.texcoordptr[0]); - } else { - DFN ( _sse_MultiTexCoord2fv_2, rmesa->vb.dfn_cache.MultiTexCoord2fvARB ); - FIXUP(dfn->code, 14, 0x0, (int)rmesa->vb.texcoordptr); +/* question: should we just let the case for RADEON_CP_VC_FRMT_ST0 for the */ +/* default path? Maybe some programs just use glMultiTexCoord2f(v)ARB for */ +/* every TMU, as GL_TEXTURE0_ARB is also allowed */
No. If some other set of texture units (say, 0 and 2 or just 1), are enabled, masking the unit with 3 won't put the data in the correct place in the vertex buffer. If just TMU 1 is enabled, it's coordinate needs to be at the 0th position. Just masking w/3 would put it at the 1st position, and the chip will get garbage.
what I tried to ask was, if it would be better to disable the fast-path for the case RADEON_CP_VC_FRMT_ST0: (as it was before.)
before TMU3-patch it was more or less: switch (statement) { case (RADEON_CP_VC_FRMT_ST0|RADEON_CP_VC_FRMT_ST1): fast-path(); break; default: default-path(); break; }
I think it should be okay to enable the fast path in this case. I think it was just an over-sight that it wasn't included in the first place. Keith may know better about that particular choice (since he made it!) :)
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
