On Sun, Aug 03, 2003 at 01:14:21PM -0700, Ian Romanick wrote: > Ville Syrjälä wrote: > > > This patch implements these extensions: > > GL_ARB_texture_env_combine > > GL_EXT_texture_env_combine > > GL_ARB_texture_env_crossbar > > > > G400 or better needed obviously. > > First let me say this: WOW. I am very impressed. I'm impressed that > you changed your mind about the viability of implementing this on MGA, > and I'm impressed that you came up with such a clean solution so quickly.
Thanks. > > I made the mapping between OpenGL args and hw args flexible. This way > > it doesn't matter in which order the user specifies the arguments. > > That's one of the tough parts of MGA. The argument ording to the > combiners is very inflexible. I like the way you did this. Me too :) > > Hw can't support dot3 stuff. Also RGB_SCALE and ALPHA_SCALE only work > > fully with GL_MODULATE. GL_REPLACE can't support this at all the others > > support only a value of 1. > > Dot3 is one of the truly frustrating things about the G400. It has all > the hardware to do it. It has the MODULATE arithmetic followed by the > ADD in almost the right way. Too bad they didn't think to wire the ADD > logic that way. :( Of course, at the time they thought EMBM was going > to be the thing of the future... Well at least ATI_envmap_bumpmap should be possible. It's on my todo list but I just wanted to get the basic stuff working first. > On GL_REPLACE, it can handle scaling in most cases. You just have to > program the alpha input to be 1, select the correct color input, and use > the modulate with the correct scale. But how do I program the alpha input to 1? I think the FCOL register is the only way to do that but then CONSTANT + SRC_ALPHA or ONE_MINUS_SRC_ALPHA wouldn't work. Maybe I should do it anyway and if are needed then do the fallback. It would affect GL_BLEND too... > > So far I've only tested with an emboss bumpmapping sample from ATI. Good > > news is that it looks ok :) It uses GL_MODULATE, GL_REPLACE and > > GL_ADD_SIGNED. Are there any other good tests I could try? > > There's always glean. If that says it's okay, then I'd have a fair > amount of confidence in it. I forgot that glean had a texcombine test too. I'll see what it has to say... > You may want to code up something simple > that will hit some of the cases that you know the hardware can't do. We > want to be sure that it does a SW fallback when it needs to. Yep. > You may also want to add an env var / config variable to disable these > extensions. There are some apps that may be slower (because they only > hit the SW fallback paths) with the extensions than without. I seem to > recall that Matrox's Windows drivers had a check-box in their config > tool to enable / disable tex_env_combine support. You'll probably want > to wait until after the config file stuff is merged to do that, but it's > your call. This is your baby, afterall. :) Yeah I'll wait for the config file stuff. > On a side note, have you looked at ATI_texture_env_combine3? When I was > looking at ARB/EXT_texture_env_combine some months ago, it seemed that > the G400 could do quite a few cases in the ATI extension as well. The > ATI extension adds 3 modulate-then-add modes. As long as there were > only two "different" inputs used, the G400 could do it. There are a few > apps (e.g. UT2k3) that like to use that extension. Thanks for the tip. The extension surely looks G400 compatible (TM). I'll add to my todo list. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ ------------------------------------------------------- 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/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
