The duplication of state data caused a crash due to double-free on destruction
of context, because a variable wasn't correctly null'ed out.
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
For some unknown reasons the scratch reg value doesn't endup in the status
map at the scratch reg offset, this is a temporary work around until we
figure out why it doesn't work.
This array was mistakenly dimensioned with VERT_ATTRIB_MAX (32) but it
should really be MAX_VERTEX_GENERIC_ATTRIBS (16).
The generic vertex attributes are in addition to the conventional arrays
(except in NV vertex program mode- they alias/overlay in that case) so
the total of all conventional attributes plus generic attributes should
total 32 (not 48).
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.
