It's possible to hand a GL_COLOR_INDEX/GL_BITMAP image to glTexImage3D()
which gets converted to RGBA via the glPixelMap tables.
This fixes a failure with piglit/fdo10370 with Gallium.
The generic_array[] is 16 elements in size, but the loop was doing 32
iterations. The out of bounds array write was clobbering the following
inputs[] array but as luck would have it, that didn't matter.
We don't really implement vertex weights but in the VBO code this
fixes and odd case for the legacy_array[] setup. Before, the
vbo->draw_prims() call was always indicating that the vertex weight
array was present/enabled when it really wasn't.
If we're running a vertex program to emulated fixed-function, we still need
to treat vertex arrays/attributes as if we're in fixed-function mode.
This should probably be back-ported to Mesa 7.5 after a bit more testing.
Noticed while debugging a weird 1D FBO testcase that left its existing
viewport and projection matrix in place when switching drawbuffers. Didn't
fix the testcase, though.
Fixes segfault on an fbo.c negative test for FBO with texture width/height
of 0. Previously we just tested for border != 0 to work around this
segfault.
In spu_tri.c:setup_sort_vertices() triangles are culled after the
vertices are sorted. This patch moves the check a little earlier
and performs the actual check a little faster through intrinsics and
a little trickery.
Reduced code size and less work is done before a triangle is deemed
OK to skip.
It was taking approximately 50 cycles to extract the vertex indices,
calculate the vertex_header pointers and call tri_draw() for each
three vertices - .
Unrolled, it takes less than 100 cycles to extract, unpack,
calculate pointers and call tri_draw() eight times. It does have a
nasty jump-tabled switch. I'm sure that there's a better way...
Code size of spu_render.o gets larger due to the extra constants and
work in the inner loop, there are extra stack saves and loads
because there are more registers in use, and an assert. spu_tri.o
gets a little smaller.
The rationale here is to avoid updating a timestamp for a file that
hasn't changed. Needless updates of the timestamp can ripple into
other projects, (xserver, etc.), useless recompiling due to a
'make install' in mesa that didn't actually change anything.
Less briefly... Shaders need to be recompiled if their constantbuf
offsets have changed. However, since we only change them from shaders if
immediates need to be emitted, we shouldn't bother if the shader doesn't
use immediates.
