i915: Only use TEXCOORDTYPE_VECTOR with cube maps on gen2

Check that the target is GL_TEXTURE_CUBE_MAP before emitting
TEXCOORDTYPE_VECTOR texture coordinates.

I'm not sure if the hardware would like CARTESIAN coordinates
with cube maps, and as I'm too lazy to find out just emit the
VECTOR coordinates for cube maps always. For other targets use
CARTESIAN or HOMOGENOUS depending on the number of texture
coordinates provided.

Fixes rendering of the "electric" background texture in chromium-bsu
main menu. We appear to be provided with three texture coordinates
there (I'm guessing due to the funky texture matrix rotation it does).
So the code would decide to use TEXCOORDTYPE_VECTOR instead of
TEXCOORDTYPE_CARTESIAN even though we're dealing with a 2D texure.
The results weren't what one might expect.

demos/cubemap still works, which hopefully indicates that this doesn't
break things.

Also tested with:
 bin/glean -o -v -v -v -t +texCube --quick
 bin/cubemap -auto
from piglit.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
This commit is contained in:
Ville Syrjälä 2014-07-02 02:23:20 +03:00
parent ca39c46c3b
commit 390799c496

View file

@ -134,27 +134,28 @@ i830_render_start(struct intel_context *intel)
GLuint mcs = (i830->state.Tex[i][I830_TEXREG_MCS] &
~TEXCOORDTYPE_MASK);
switch (sz) {
case 1:
case 2:
emit = EMIT_2F;
sz = 2;
mcs |= TEXCOORDTYPE_CARTESIAN;
break;
case 3:
if (intel->ctx.Texture.Unit[i]._Current->Target == GL_TEXTURE_CUBE_MAP) {
emit = EMIT_3F;
sz = 3;
mcs |= TEXCOORDTYPE_VECTOR;
break;
case 4:
emit = EMIT_3F_XYW;
sz = 3;
mcs |= TEXCOORDTYPE_HOMOGENEOUS;
break;
default:
continue;
};
} else {
switch (sz) {
case 1:
case 2:
case 3:
emit = EMIT_2F;
sz = 2;
mcs |= TEXCOORDTYPE_CARTESIAN;
break;
case 4:
emit = EMIT_3F_XYW;
sz = 3;
mcs |= TEXCOORDTYPE_HOMOGENEOUS;
break;
default:
continue;
}
}
EMIT_ATTR(_TNL_ATTRIB_TEX0 + i, emit, 0);
v2 |= VRTX_TEX_SET_FMT(count, SZ_TO_HW(sz));