I want to clear something up.
EXT_texture_lod_bias provides a per-stage bias to a texture’s LOD.
ARB_fragment_program throws away all per-stage data (parameters set by glTexEnv*). Indeed, it seems to throw away the concept of a stage in favor of the concept of a “texture image unit”.
Does this means that EXT_texture_lod_bias doesn’t work with fragment programs? Or does it mean that there is some per-stage state that is transfered over to the concept of a “texture image unit”?
Filters etc are set in texture parameters, not the texture environment. In a fragment program you just fetch a value from a texture unit using a specified texture coordinate. The idea of a fragment program is to replace the arithmetic in fixed function texture environments with something more flexible. BUT when you fetch a coordinate, the filters like MIP mapping are applied before the fragment program sees the result, it just happens automatically according to the state associated with the texture object.
The only curiosity here is that there is a special fetch instructions that uses bias, don’t ask me why, so if you want to use the bias set by your OpenGL C code with a texture parameter call, use the TXB instruction.
[This message has been edited by dorbie (edited 05-25-2003).]
Filters etc are set in texture parameters, not the texture environment. In a fragment program you just fetch a value from a texture unit using a specified texture coordinate.
EXT_texture_lod_bias is not a glTexParameter setting. As I pointed out, it is a glTexEnv setting. Why nVidia (the makers of the extension) picked it that way, I don’t know, as it is similar enough to texture filtering to be considered one and the same.
The only curiosity here is that there is a special fetch instructions that uses bias, don’t ask me why
That bias is so that you can change the LOD bias per-fragment. Which can be useful for things like cheap depth-of-field effects, etc.
A quote from one of the issues in the NV_fragment_spec:
In both cases [note: both the TEX and the TXP instruction], the GL will automatically compute partial derivatives used for filter and LOD selection.
Judging from this, one could assume that the LOD bias is still computed as before, but I haven’t tested it.
EXT_texture_lod_bias is not a glTexParameter setting.
True, but this was fixed in OpenGL 1.4 where there is both a per-unit and a per-texture object LOD bias.
Why nVidia (the makers of the extension) picked it that way, I don’t know.
According to the EXT_texture_lod_bias specification because that’s the way things are in D3D (which doesn’t have any per-texture object state at all). But I also think it should be a per-texture object state.
[This message has been edited by Asgard (edited 05-26-2003).]
Hmm… interesting that NVIDIA added this as a texture environment token initially. The earlier (but different) SGI LOD bias extensions used texture parameters calls.
I did see this in a Mark Kilgard GDC2000 overview on extensions, where he wrote the following 
glTexParameterf(GL_TEXTURE_FILTER_CONTROL_EXT, GL_TEXTURE_LOD_BIAS_EXT, 0.25);
Page 50:
http://developer.nvidia.com/docs/IO/1377/ATT/GDC2K_ogl_extensions.pdf
dunno why, these things are difficult to track over time.
I missed the additional per fragment argument, I shoulda known it was for per fragment bias support.
[This message has been edited by dorbie (edited 05-26-2003).]
Here’s what ARB_fragment_program says about TXB:
It should be noted here that the bias introduced per-fragment by TXB is added to any per-object or per-stage LOD bias. If per-fragment LOD bias is not necessary, using the per-object and/or per-stage LOD biases may perform better.
This seems to indicate that per-object and per-stage LOD biases are always taken into account when texturing, but the description of TXP and TEX are mute on the matter, one way or another.
Anyway, from reading the spec, I’d assume that texture lod biasing SHOULD happen for all fetches using all three texture opcodes; the difference with TXB is that you get an additional per-fragment bias.
Yep I read that after korval’s response, it does seem untidy, as per Korval’s original post.
P.S. I’m going senile, I’ve actually used the texenv version of this a long time ago 
[This message has been edited by dorbie (edited 05-26-2003).]