The old behaviour depended on which texture images the fragment program
reads from, which seems to contradict the shader specifications.
Note: Piglit's general/texgen test checks for this problem.
If the 'shader' parameter is wrong, need to either generate GL_INVALID_VALUE
or GL_INVALID_OPERATION. It depends on whether 'shader' actually names a
'program' or is a totally unknown ID.
There might be other cases to fix...
This fixes a failure for cases like:
vec4 v;
v[1] *= 2.0;
The v[1] actually acts like a writemask, equivalent to v.y
The fix is a bit convoluted, but will do for now.
Before, the presence of a 'return' statement always prevented inlining
a function. This was because we didn't want to accidentally return from
the _calling_ function. We still need the semantic of 'return' when inlining
but we can't always use unconditional branches/jumps (GPUs don't always
support arbitrary branching).
Now, we allow inlining functions w/ return if the return is the last
statement in the function. This fixes the common case of a function
that returns a value, such as:
vec4 square(const in vec4 x)
{
return x * x;
}
which effectively compiles into:
vec4 square(const in vec4 x)
{
__retVal = x * x;
return;
}
The 'return' can be no-op'd now and we can inline the function.
This isn't complete yet. It does cover the two most common usage cases,
though, and at least the third one (POINT_DISTANCE_ATTENUATION) is possible,
so I'll do that later.
. There is both a per-texture unit and a per-texture object (at least for
OpenGL 1.4); this should now be supported properly.
. The LOD bias calculation in r300_state has been simplified and corrected
(need to multiply by 32 instead of 31, and ensure clamping)
. do not clamp LOD bias in TexEnv, as that behaviour conflicts with what
the spec says
. set Const.MaxTextureLodBias properly
. remove the no_neg_lod_bias property; if somebody can explain what
it's good for, we can add it back in, but according to Google, nobody
seems to use it
. removed some dead code and unused variables
The operation doesn't really make sense. It triggered a bug in the r300 DRI
driver (and possibly other drivers that simulate 1D textures via 2D textures).
I've added an isolated test case for this bug to Piglit, so everybody wins.
