Basically, the application enables client vertex and color arrays,
renders something, then disables color array, and renders something
else (using vertex array only). Even though the color array is
disabled (and the pointer is no longer valid), the driver still tries
to read color data from this array (which results in an exception).
This is because enabling/disabling array does not trigger
_ae_update_state() and the list of enabled arrays is not updated.
_ae_update_state() it's called on the first state validation only (as
all the "dirty" flags are set at the beginning). Any further change to
client arrays' state has no effect.
Otherwise, we would ping-pong objects to GTT and back as we did pwrite on
indices (flushed and mapped to GTT) and mapped for vertices (moved back to
CPU domain).
Fixes bug #17180.
If we copy the area before reporting the damage in this area, the server may
restore buffered data over the new data, leading to artefacts on the screen.
Reproducable with two cursors (second of which is SW rendered) and moving
windows around in compiz.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=16384 .
Previously, the updated images would be ignored because the miptree in the
image matched the miptree in the object, even though Mesa core had just attached
updated contents in ->Data. Additionally, Mesa core could have tried to
free inside our miptree if it had already been validated.
Fixes bug #17077.
Conflicts:
src/mesa/drivers/dri/intel/intel_span.c
src/mesa/main/fbobject.c
This converts the i915 driver to use the GEM interfaces for object management.
To do this, I had to clean up some of 965 state upload stuff. We may end
up over-emitting state in the aperture overflow case, but that should be rare,
and I'd rather have the simplification of state management.
inst->TexSrcUnit is used as an index into program->SamplerUnits[] since
the commit ade508312c, and program->SamplerUnits
is a sampler-to-texture-unit mapping.
