On Mon, 25 Feb 2002, José Fonseca wrote: > On 2002.02.25 00:58 Leif Delgass wrote: > > 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 > > I've also been studying this but I'm far behind you, so I still didn't > understood very well what is the problem. > > The TEX_LIGHT_FCN register (Mach64 Spec. p. 6-9) programed to values 0,1 > and 2, matches the REPLACE, MODULATE, and DECAL definition (OpenGL Spec p. > 148, t. 3.22). For modulate it says: output color = texel color * > interpolator color. So the only way this does not comply is if in this > operation the color multiplication doesn't include the alpha component, > but I didn't see any reference of that.
It doesn't explicitly state it in the docs, but it's not multiplying the fragment alpha and texture alpha components. Instead, the texture alpha value is used as the resulting alpha value of the texture application (which can then be blended with the framebuffer depending on the blend function specified in ALPHA_TEST_CNTL). To see it you can change the alpha values of a couple of vertices of the smooth shaded quad in the texenv demo. I can post a patch to toggle this. If the image format does not have an alpha component (or that component is always 1), you clear TEX_MAP_AEN and then the alpha value from the fragment (the alpha interpolater for the underlying polygon) is used. > The only Utah-GLX comment to this is at mach64state.c:434, when setting > the ALPHA_TST_SRC_SEL (Mach64 Spec. p. 5-19), and I don't understand what > "modulated values" this refers to: > > /* we are going to always take the texel alpha, because > we can't get modulated values (rage pro limitation), > and alpha testing from vertex shading doesn't make much > sense */ > asrc = 0; This is what I was referring to. The texture alpha is always used if the texture format has an alpha component, since the hardware can't modulate the interpolated alpha of the polygon with the texture alpha. > I hadn't been able to experiment this though (too busy lately), but I also > don't know if the current DRI driver mimics the Utah-GLX behaviour or not > (I have to study it first). The Utah-glx driver is defenitely not compliant here. For example, it just falls back to GL_MODULATE when GL_BLEND is the texture environment state. > > 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. > > > > I think that a common way to configurate the driver settings would be > excelent. A > configuration file that had default settings aiming OpenGL conformance and > per-application configuration would be a neat and clean way to deal with > these kind of subjects. Brian had mentioned a reluctance to use environment vars which is why I brought this up, but we seem to have a bit of a special case where the hardware isn't compliant with some core OpenGL functions that are used often. If we are going to use environment vars, there should be some consistency to the way they are used across drivers. > > 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. > > > > State vector refers to _all_ OpenGL state variables, and the texture > environment mode isn't mentioned even in the "Stronly suggested" of > invariance rule 2. "Blend parameters" is though, but in the "Stronly", not > "required". > > I think that one has to have in mind that OpenGL conformance is not an end > on itself. Nobody buys a 3D graphics card for having a better OpenGL > conformance but for more performance. OpenGL conformance is, of course, > very important otherwise it negates the whole point of using OpenGL, but I > think that we, as implementors, have to have in mind what the enduser > expects of a 3D driver, so we should give a option to trade the > conformance for performance. This way we can clame OpenGL conformance, but > at the same time meet the different user expectations. A lot of people _are_ concerned about compliance. The behavior needs to be predictable and repeatable according to the spec, or the spec doesn't have much meaning. Some apps/users may be more concerned with correct rendering than speed (e.g. you could capture the framebuffer output for non-real-time rendering). As I said, the hardware isn't compliant with some core OpenGL features, whereas most new hardware is only lacking in more recent features (often extensions to the spec which can be queried for). Ideally, our implementation should be as compliant as possible, leaving it up to applications to work around the limitations (Quake 3 does this for example, but it's a hack that looks for "Rage Pro" in the renderer string), or to let the user configure the application to not use functionality which is slow. But a lot of apps are going to take it for granted that this functionality is there, so if the app doesn't allow for configuring around the limitation, we can provide that switch in the driver. I think it's important to try to make the common cases fast, but not sacrifice correct rendering for apps that need it. > > 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. > > > > I'm looking forward to that too. > > > -- > > Leif Delgass > > Regards, > > José Fonseca > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > -- Leif Delgass http://www.retinalburn.net _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
