Create a texture matching the bitmap image and use a fragment program
to modulate current raster color by the boolean-valued texture. Need to
eventually use fragment culling (see comments in code).
Previously, programs were translated independently during validation.
The problem is the translation to TGSI format, which packs shader
input/outputs into continuous slots, depends on which vertex program is
being paired with which fragment shader. Now, we look at the outputs
of the vertex program in conjunction with the inputs of the fragment shader
to be sure the attributes match up correctly.
The new 'linked_program_pair' class keeps track of the associations
between vertex and fragment shaders. It's also the place where the TGSI
tokens are kept since they're no longer per-program state but per-linkage.
Still a few loose ends, like implementing some kind of hash/lookup table
for linked_program_pairs.
Build a buffer of contigous vertices and indices at the backend of our
software transformation/clipping path. This will become the mechanism
for emitting buffers of vertices to rasterization hardware.
This is similar to but not the same as the post-transform vertex cache.
In particular, these vertices are subject to clipping, culling, poly offset,
etc. The vertices emitted will all be used by hardware.
TODOs include the actual transformation to hardware vertex formats, moving
this out of softpipe to somewhere more useful and allowing >1 primitive to
share the generated VB.
This branch replaces the DRM pool interface used by i915tex with a "dri_bufmgr"
interface in dri/common which may be set up to use either TTM or traditional
static memory management according to what is available. The i915tex TTM
code now requires an updated DDX which provides proper buffer objects for the
static front/back/depth, instead of using fake buffers. The driver is now
built as i915_dri.so, and should replace the old i915 driver shortly.
