i915 actually supports up to 4 (according to header file - not tested),
i965 up to 16 (code already handled this but slightly broken), so don't use 2
for all chips, even though angular dependency is very high.
This is a follow-on to commit c1a3b85280.
Note that (at this time) wherever _NEW_PROGRAM_CONSTANTS is set we're still
setting _NEW_PROGRAM so this won't really make any difference (for now).
Need to do this to ensure vbo code unmaps its buffers before calling
the driver, which may be sitting on top of a memory manager which
objects to firing commands from a mapped buffer.
This state flag will be used to indicate that vertex/fragment program
constants have changed. _NEW_PROGRAM will be used to indicate changes
to the vertex/fragment shader itself, or misc related state.
_NEW_PROGRAM_CONSTANTS is also set whenever a program parameter that's
tracking GL state has changed. For example, if the projection matrix is
in the parameter list, calling glFrustum() will cause _NEW_PROGRAM_CONSTANTS
to be set. This will let to remove the need for dynamic state atoms in
some drivers.
For now, we still set _NEW_PROGRAM in all the places we used to. We'll no
longer set _NEW_PROGRAM in glUniform() after drivers/etc have been updated.
Return the conservative PIPE_REFERENCED_FOR_READ | PIPE_REFERENCED_FOR_WRITE
value for now.
This fixes a bunch of regressions seen in piglit and glean.
This needs a proper fix to propogate the out-of-memory condition back
up to Mesa and the app as a GL error. Until then, at least catch the
problem at its source.
The READ message's msg_control value can be 0 or 1 to indicate that the
Oword should be read into the lower or upper half of the target register.
It seems that the other half of the register gets clobbered though. So
we read into two dest registers then use a MOV to combine the upper/lower
halves.
Now that we have real constant buffers, the demands on the CURBE are lessened.
When we use real VS/WM constant buffers we only use the CURBE for clip planes.
