Re: [Dri-devel] Compliance v. Performance (and mach64)

[Leif D. <lde...@re...>]

On Mon, 25 Feb 2002, Jos=E9 Fonseca wrote:

> On 2002.02.25 00:58 Leif Delgass wrote:
> > In investigating texture environment modes on the mach64, I've discov=
ered
> > that the card can't modulate fragment and texture alpha values (this =
is
> > confirmed by the docs, experimentation, and comments in the utah-glx
>=20
> I've also been studying this but I'm far behind you, so I still didn't=20
> understood very well what is the problem.
>=20
> The TEX_LIGHT_FCN register (Mach64 Spec. p. 6-9) programed to values 0,=
1=20
> and 2, matches the REPLACE, MODULATE, and DECAL definition (OpenGL Spec=
 p.=20
> 148, t. 3.22). For modulate it says: output color =3D texel color *=20
> interpolator color. So the only way this does not comply is if in this=20
> operation the color multiplication doesn't include the alpha component,=
=20
> 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 doe=
s
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=
=20
> the ALPHA_TST_SRC_SEL (Mach64 Spec. p. 5-19), and I don't understand wh=
at=20
> "modulated values" this refers to:
>=20
> 		/* 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=20
> sense */
> 		asrc =3D 0;

This is what I was referring to.  The texture alpha is always used if the=
=20
texture format has an alpha component, since the hardware can't modulate=20
the interpolated alpha of the polygon with the texture alpha.

> I hadn't been able to experiment this though (too busy lately), but I a=
lso=20
> don't know if the current DRI driver mimics the Utah-GLX behaviour or n=
ot=20
> (I have to study it first).

The Utah-glx driver is defenitely not compliant here.  For example, it=20
just falls back to GL_MODULATE when GL_BLEND is the texture environment=20
state.

> > source).  The one exception being that there are a couple of bizarre
> > "alpha masking" modes that allow you to modulate the fragment alpha w=
ith
> > the texture alpha's most significant or least significant bit.  The=20
> > _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).
> >=20
> > Given this hardware limitation, most GL_MODULATE cases can produce
> > incorrect results with alpha blending enabled.  Using software fallba=
cks
> > for these cases could seriously impact performance in applications th=
at
> > make heavy use of these modes.  So my question is this: what's the be=
st
> > way to handle compliance v. performance?  I can use software renderin=
g 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 would=
n't
> > notice so much if the fallback cases are used sparingly in an app.  T=
hen
> > gamers could enable the hardware implementation to get better
> > performance,
> > at the cost of some rendering problems.  There doesn't seem to be a G=
L
> > 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 lik=
e
> > the
> > only alternative.  Of course the advantage of an environment var is t=
hat
> > it can be set per app.
> >=20
>=20
> I think that a common way to configurate the driver settings would be=20
> excelent. A
> configuration file that had default settings aiming OpenGL conformance =
and=20
> per-application configuration would be a neat and clean way to deal wit=
h=20
> these kind of subjects.

Brian had mentioned a reluctance to use environment vars which is why I=20
brought this up, but we seem to have a bit of a special case where the=20
hardware isn't compliant with some core OpenGL functions that are used=20
often.  If we are going to use environment vars, there should be some=20
consistency to the way they are used across drivers.

> > Another issue is granularity of the hardware/software switch: if I ca=
n do
> > GL_MODULATE correctly in hardware when the texture format is GL_RGB o=
r
> > GL_LUMINANCE, can I use hardware for that case even if I'm using soft=
ware
> > for all the other texture formats?  The invariance rules seem to sugg=
est
> > 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", whe=
reas
> > I'm interpreting the GL_TEXTURE_ENV_MODE as a "mode vector".  If "mod=
e
> > vectors" are only state variables changed with glEnable/glDisable, th=
en
> > the perfomance outlook for alpha blending would be pretty dire if I n=
eed
> > to use software for _all_ environment modes.
> >=20
>=20
> State vector refers to _all_ OpenGL state variables, and the texture=20
> environment mode isn't mentioned even in the "Stronly suggested" of=20
> invariance rule 2. "Blend parameters" is though, but in the "Stronly", =
not=20
> "required".
>=20
> I think that one has to have in mind that OpenGL conformance is not an =
end=20
> on itself. Nobody buys a 3D graphics card for having a better OpenGL=20
> conformance but for more performance. OpenGL conformance is, of course,=
=20
> very important otherwise it negates the whole point of using OpenGL, bu=
t I=20
> think that we, as implementors, have to have in mind what the enduser=20
> expects of a 3D driver, so we should give a option to trade the=20
> conformance for performance. This way we can clame OpenGL conformance, =
but=20
> 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 doe=
s
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.
=20
> > What are people's ideas on this, and how do other drivers address the=
se
> > 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.
> >=20
>=20
> I'm looking forward to that too.
>
> > --
> > Leif Delgass
>=20
> Regards,
>=20
> Jos=E9 Fonseca
>=20
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>=20

--=20
Leif Delgass=20
http://www.retinalburn.net