On Mon, 09 May 2005 19:09:40 +0100
Keith Whitwell <[EMAIL PROTECTED]> wrote:

> Aapo Tahkola wrote:
> > On Tue, 03 May 2005 14:59:53 +0100
> > Keith Whitwell <[EMAIL PROTECTED]> wrote:
> > 
> > 
> >>Aapo Tahkola wrote:
> >>
> >>>On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
> >>>Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>
> >>>>On Thu, 21 Apr 2005, Aapo Tahkola wrote:
> >>>>
> >>>>
> >>>>
> >>>>>On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
> >>>>>Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>  With regard to state switching, it might be worth it to simply hash
> >>>>>>various configuration (fog on /fog off, etc) and just upload state
> >>>>>>difference on such changes.
> >>>>>
> >>>>>Could work reasonably well. Problem with hashing all programs is that we 
> >>>>>would most likely have so many different programs that it would be 
> >>>>>undesirable to keep them in memory. Take for example omiting tex coord 
> >>>>>transforms, rescaling of normals, normalization of normals..
> >>>>>Sure we could just start dropping them but that might lead to instable 
> >>>>>framerates if we constantly translate new programs.
> >>>>>I cant say I knew any really good way to handle this at the moment so 
> >>>>>its probably best to try something and see what problems arise.
> >>>>
> >>>>Well, we know that the register space we are interested in is less than 
> >>>>4K.
> >>>>A megabyte would hold 256 such configurations - should be plenty, no ?
> >>>
> >>>
> >>>Maybe for average case but not for worst.
> >>>
> >>>Heres a list of problems that prevent r300 driver from using Keith's ffp 
> >>>program generator:
> >>>1. _TnlProgram is of fixed size type and smaller than r300_vertex_program 
> >>
> >>What's the actual issue here?  In what circumstances does this cause a 
> >>problem?
> > 
> > 
> > Mesa is holding drivers private data bound to programs in containers just 
> > like in i915NewProgram.
> > I suggest this to be sorted out by adding PrivatePrt to vertex and fragment 
> > program structures in Mesa.
> > This way drivers can allocate their private structures at translation stage 
> > and more better estimate needed memory.
> > Also this fits well into the hashing scheme when arb programs generated by 
> > t_vp_build.c could be destroyed once no longer needed.
> 
> I think the issue is that I was creating the structures directly rather 
> than calling ctx->Driver.NewProgram() to do this, as is the case with 
> all other fragment & vertex programs.

Or that.

Heres a better version of the mov changes.
Changes to build_texture_transform should still break software tnl though.

> The issue of creating/destroying the programs should probably be done at 
> a higher level, ie in mesa/main/texenvprogram.c, so that drivers don't 
> all end up with similar different hashing schemes.

I agree.

-- 
Aapo Tahkola
Index: t_vp_build.c
===================================================================
RCS file: /cvs/mesa/Mesa/src/mesa/tnl/t_vp_build.c,v
retrieving revision 1.10
diff -u -b -B -u -r1.10 t_vp_build.c
--- t_vp_build.c        11 May 2005 15:18:59 -0000      1.10
+++ t_vp_build.c        11 May 2005 16:12:55 -0000
@@ -103,6 +103,8 @@
 #define Y    SWIZZLE_Y
 #define Z    SWIZZLE_Z
 #define W    SWIZZLE_W
+#define ONE  SWIZZLE_ONE
+#define ZERO SWIZZLE_ZERO
 
 
 /* Construct a ureg:
@@ -968,10 +970,11 @@
    for (i = 0; i < ctx->Const.MaxTextureCoordUnits; i++) {
       struct gl_texture_unit *texUnit = &ctx->Texture.Unit[i];
       GLuint texmat_enabled = ctx->Texture._TexMatEnabled & ENABLE_TEXMAT(i);
-      struct ureg out = register_output(p, VERT_RESULT_TEX0 + i);
+      struct ureg out;
 
       if (texUnit->TexGenEnabled || texmat_enabled) {
         struct ureg out_texgen = undef;
+        out = register_output(p, VERT_RESULT_TEX0 + i);
 
         if (texUnit->TexGenEnabled) {
            GLuint copy_mask = 0;
@@ -1095,6 +1098,35 @@
 
 static void build_passthrough( struct tnl_program *p, GLuint inputs )
 {
+   GLcontext *ctx = p->ctx;
+   GLuint i, nr_lights = 0;
+   
+   if (ctx->Light.Enabled == GL_FALSE)
+      emit_op1(p, VP_OPCODE_MOV, register_output(p, VERT_RESULT_COL0), 0,
+                           register_input(p, VERT_ATTRIB_COLOR0));
+   else {
+     
+      for (i = 0; i < MAX_LIGHTS; i++) 
+         if (ctx->Light.Light[i].Enabled)
+          nr_lights++;
+      
+      if(nr_lights == 0) { /* Darkness */
+         struct ureg dummy = register_input( p, VERT_ATTRIB_POS );
+        
+         emit_op1(p, VP_OPCODE_MOV, register_output(p, VERT_RESULT_COL0), 0,
+                             swizzle(dummy, ZERO, ZERO, ZERO, ZERO));
+      }
+   }
+   
+   for (i = 0; i < ctx->Const.MaxTextureCoordUnits; i++) {
+      struct gl_texture_unit *texUnit = &ctx->Texture.Unit[i];
+      GLuint texmat_enabled = ctx->Texture._TexMatEnabled & ENABLE_TEXMAT(i);
+      
+      if ((! (texUnit->TexGenEnabled || texmat_enabled)) && 
texUnit->_ReallyEnabled) {
+        struct ureg out = register_output(p, VERT_RESULT_TEX0 + i);
+        emit_op1(p, VP_OPCODE_MOV, out, 0, register_input(p, 
VERT_ATTRIB_TEX0+i)); 
+      }
+   }
 }
 
 

Reply via email to