i965: Use linker-assigned sampler IDs in instruction encoding.

i965: Use linker-assigned sampler IDs in instruction encoding.

When assigning uniform locations, the linker assigns each sampler
uniform a sequential numerical ID.  gl_shader_program::SamplerUnits maps
these sampler variable IDs to the actual texture units they reference
(specified via glUniform1i).

Previously, we encoded this mapping in the SEND instruction encoding:
the "sampler" was the texture unit number, and the binding table index
was SURF_INDEX_TEXTURE(the texture unit number).  This unfortunately
meant that whenever the application changed the value of a sampler
uniform, we had to recompile the shader to change the SEND instructions.

This was horrible for the game Cogs, which repeatedly switches between
using texture unit 0 and 1.  It also made fragment shader precompiles
useless: we'd do the precompile at glLinkShader() time, before the
application called glUniform1i to set the sampler values.  As soon as
it did that, we'd have to recompile, wasting time and space in the
program cache.

This patch encodes the SamplerUnits indirection in the binding table,
sampler state, and sampler default color tables.  Instead of baking the
texture unit number into the shader, we bake in the sampler variable ID
assigned by the linker.  Since those never change, we don't need to
recompile programs on uniform changes.

This does mean that the tables now depend on the linked shader program
being used for rendering, rather than simply representing all available
texture units.  This could cause an increase in state emission.

Another plus is that the sampler state and sampler default color tables
are now compact: we only emit as many entries as there are sampler
uniforms, with no holes in the table since the new sampler IDs are
sequential.  Previously we had to emit a full 16 entries every time,
since the tables tracked the state of all active texture units.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>