On Mon, Jul 21, 2003 at 07:54:31AM -0700, Ian Romanick wrote: > Ville Syrj�l� wrote: > > > On Thu, Jul 17, 2003 at 12:51:09PM -0700, Ian Romanick wrote: > > > >>Ville Syrj�l� wrote: > >> > >>>mga_texenv.patch: > >>>- Fix all texenv modes for all texformats on G400. > >>> > >>>- Implement GL_DECAL using linear blend mode. > >>> The G400 docs aren't very clear on this subject so I'm not entirely sure > >>> if it will work correctly with multi texturing. Anyone have a good test? > >>> > >>>- GL_BLEND suffers from hardware limitations. All three components of Cc > >>> must be equal. Additionally GL_INTENSITY requires that Ac is 0.0 or 1.0. > >>> If Cc!=0.0 (or Ac!=0.0 for GL_INTENSITY) we need both units to get > >>> things done in a single pass. > >> > >>Here's another thought that I've been toying with. All of the "classic" > >>texture environments are a subset of the texture combine environment. > >>That is, all of the equations for REPLACE, MODULATE, DECAL, BLEND, and > >>ADD can be implemented using COMBINE. Why not implement the driver that > >>way? Why not have a generic updateTexEnv routine that has a big switch > >>based on the texture environment with inner-switches based on texture > >>base format. Each case in the inner-switches would call a device > >>specific UpdateTexEnvCombine routine with the right values. > >> > >>Doing this for chips like the Radeon, R200, and i830 that actually > >>support all of ARB_texture_env_combine would be easy. Doing it for > >>chips like the Rage128 and G400 would be more difficult. There would be > >>a lot of software fallbacks, but those drivers have software fallbacks > >>for the "classic" texture environments as it is. > > > > > > I took a brief look at this stuff for G400 but came to the conclusion that > > pretty much anything beyond the normal texenv modes would be a fallback. > > So I doubt there's much point in doing this. > > There would be a lot of fallbacks. However, there would be a lot of > cases that wouldn't be fallbacks. That wasn't the issue I was concerned > about (i.e., that's not what has stopped me from already doing the > work). The problem is that it would be a lot of effort to sort all the > different cases out and generate the right register values. > > When I was looking into it, I figured out that about 50% of the > ARB_texture_env_combine modes could be supported and about 30% of the > ATI_texture_env_combine3 modes could be supported. In the general case, > most of the modes *except* the following could be supported: > > - Anything that requires more than a single modulate (i.e., INTERPOLATE > is right out).
Actaully I think that the linear blending mode would allow INTERPOLATE to work. Arg2 would have quite serious restrictions to make it work. COMBINE_ALPHA == INTERPOLATE would be out of the question since alpha processing unit is much more limited than the color unit. > - Anything that requires arg0 to be anything other than TEXTURE (i.e., > PRIMARY_COLOR - TEXTURE is out). > - Many uses (but not all) of CONSTANT where ((Rc != Gc) && (Rc != Bc)). Yep. It's a shame the color unit can't accept three color arguments. That would lift a lot of the restrictions. <snip> > The most important change here is to make sure that lastLevel is set to > firstLevel if mipmapping isn't used, correct? Actually I just did that because I didn't see much point in uploading unused levela. The impotant change is firstLevel = BaseLevel without that you would end up watching untextured polygons. -- Ville Syrj�l� [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
