Roland Scheidegger wrote: > Brian Paul wrote: > >>>In any case, the tnl pipeline needs to be fixed for the drivers not >>>allowing per-fragment fog. >> >>I was looking at the code in r200_vertprog.c that appends the >>instructions for the three fog modes. >> >>I'm wondering if it would be better to add a new function to >>src/mesa/shader/programopt.c to add the extra fog instructions to a >>vertex program before its compiled into the r200 code. The idea being >> code re-use and driver simplification. >> >>Though, I haven't looked at things close enough yet to know if that has >>any pitfalls. > > This is a nice idea (note that the t_vp_build.c code adds its own fog > factor computation too). > I think the main drawbacks would be that you couldn't really optimize it > for a given hw target. For example, the code in t_vp_build.c does > clamping (for GL_LINEAR fog) which just doesn't seem to be necessary on > r200 as it seems to get clamped later anyway. It would be hard to > optimize that away later. Similar, you'd need to use an additional > constant and the POW opcode since there's no exponentiation with base e > opcode (which might be faster on r200).
We could easily add a new, internal opcode for that which wouldn't be otherwise exposed. > The code in programopt.c also would need to be changed to allow > modification of the program, as the fog mode may change (though I guess > that would be rare in practice). Might be easier to just reparse the > program string maybe. We could append the extra fog instructions to a temporary copy of the program, then discard it after the r200 program is generated. Or generate a second program with nothing but the fog code, translate to r200 instructions, then append it. Or something like that. > Though now that I'm looking at that tnl fog code again, is that absolute > value of the input for GL_EXP fog actually correct (both in t_vp_build.c > and t_vb_fog.c)? It seems like it would be needed if the fog coord > source is FRAGMENT_DEPTH, but I'm not sure about FOG_COORD_SRC. Well the > spec says "Q: Should the fog coordinate be restricted to non-negative > values? A: Perhaps" (!?!) If it's not restricted, then using fabs surely > won't produce the intended result. The OpenGL spec says that the Z value which is plugged into the fog expression is the _distance_ to the eye at (0,0,0,1) and may be implemented as |Ze| (where Ze is the eye coordinate Z value) rather than sqrt(Xe^2 + Ye^2 + Ze^2) which would be more realistic. It's supposed to be positive. I've actually tested and verified that other OpenGL drivers use the absolute value. -Brian ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
