When a vertex shader uses generic vertex attribute 0, but not gl_Vertex,
we need to set attribute[16] to point to attribute[0]. We were setting the
attribute size, but not the pointer.
Fixes crash in glsl/multitex.c when using the VertCoord attribute instead
of gl_Vertex.
If the multitex.vert shader uses the VertCoord generic vertex attribute
instead of the pre-defined gl_Vertex attribute, we need to make sure that
VertCoord gets bound to generic vertex attribute zero.
That's because we need to call glVertexAttrib2fv(0, xy) after all the other
vertex attributes have been set since setting generic attribute 0 triggers
vertex submission. Before, we wound up issuing the vertex attributes in
the order 0, 1, 2 which caused the first vertex to be submitted before all
the attributes were set. Now, the attributes are set in 1, 2, 0 order.
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.
Brian Paul
Eric Anholt
Jonathan Adamczewski