I managed to revert the change from unlinked at some point while
cleaning up the changes. glsl-fs-raytrace-bug27060 drops from 389
instructions to 370.
This pulls in multiple i965 driver fixes which will help ensure better
testing coverage during development, and also gets past the conflicts
of the src/mesa/shader -> src/mesa/program move.
Conflicts:
src/mesa/Makefile
src/mesa/main/shaderapi.c
src/mesa/main/shaderobj.h
This is an invasive set of changes. Each user shader tracks a set of other
shaders that contain built-in functions. During compilation, function
prototypes are imported from these shaders. During linking, the
shaders are linked with these built-in-function shaders just like with
any other shader.
This is quite a large patch because breaking it into smaller pieces
would result in the tree being intermitently broken. The big changes
are:
* Add the ir_var_temporary variable mode
* Change the ir_variable constructor to take the mode as a
parameter and correctly specify the mode for all ir_varables.
* Change the linker to not cross validate ir_var_temporary
variables.
* Change the linker to pull all ir_var_temporary variables from
global scope into 'main'.
The node being processed may be removed from the list and put in a
different list. Not using the safe version caused list processing to
change streams after moving a node.
For the shader containing 'main', use the linked shader (i.e., the
clone of the original shader that contained main) as the source for
global instructions to move into main.
Find instructions in all shaders that are not contained in a function
(i.e., initializers for global variables). "Move" these instructions
to the top of the main function in the linked shader. As a
side-effect, many global variables will also be copied into the linked
shader.
This currently involves an ugly hack so that every link doesn't result
in all the built-in functions showing up as multiply defined. As soon
as the built-in functions are stored in a separate compilation unit,
ir_function_signature::is_built_in can be removed.
Uses of the bits for allocation are offset by 16, and
VERT_BIT_GENERIC0 already has the 16 offset. As a result, it was
preventing the wrong thing from being allocated.
Eric Anholt
Ian Romanick