In investigating texture environment modes on the mach64, I've discovered that the card can't modulate fragment and texture alpha values (this is confirmed by the docs, experimentation, and comments in the utah-glx source). The one exception being that there are a couple of bizarre "alpha masking" modes that allow you to modulate the fragment alpha with the texture alpha's most significant or least significant bit. The _only_ way I can see this being useful is if the texture only uses 0 and/or 1 as alpha values. You'd have to search every textel for fractional alpha values to determine if you could use this feature, which just doesn't seem worth it (plus it would violate OpenGL invariance rules).
Given this hardware limitation, most GL_MODULATE cases can produce incorrect results with alpha blending enabled. Using software fallbacks for these cases could seriously impact performance in applications that make heavy use of these modes. So my question is this: what's the best way to handle compliance v. performance? I can use software rendering by default when alpha blending is enabled to always give correct results, and offer an environment variable switch to use the flawed hardware implementation. If you have a fast enough processor, maybe you wouldn't notice so much if the fallback cases are used sparingly in an app. Then gamers could enable the hardware implementation to get better performance, at the cost of some rendering problems. There doesn't seem to be a GL API method for conveying that a core feature like this (not an extension) is broken or slow, so an environment var or config file option seems like the only alternative. Of course the advantage of an environment var is that it can be set per app. Another issue is granularity of the hardware/software switch: if I can do GL_MODULATE correctly in hardware when the texture format is GL_RGB or GL_LUMINANCE, can I use hardware for that case even if I'm using software for all the other texture formats? The invariance rules seem to suggest that the answer is no (Appendix A, Section A.4 in the 1.3 OpenGL spec). The texture format is more of a "parameter" than a "mode vector", whereas I'm interpreting the GL_TEXTURE_ENV_MODE as a "mode vector". If "mode vectors" are only state variables changed with glEnable/glDisable, then the perfomance outlook for alpha blending would be pretty dire if I need to use software for _all_ environment modes. What are people's ideas on this, and how do other drivers address these issues? It seems that a consensus or standard for DRI drivers would be helpful (utah-glx had glx.conf). Maybe we could discuss this in tomorrow's irc meeting. -- Leif Delgass http://www.retinalburn.net _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
