i965/fs: Skip global copy propagation step.

The dataflow analysis used for global copy propagation is severely
broken, and I believe it doesn't actually do anything.  Fixing it will
require a lot of changes, each of which might break things.

Once all the fixes land, we can re-enable this.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965/fs: Switch to a do-while loop in copy propagation dataflow.

The fixed-point algorithm needs to run at least once, so a do-while loop
is more natural.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965/fs: Rename "cont" to "progress" in dataflow algorithm.

This variable indicates that the fixed-point algorithm made changes to
the data at this step, so it needs to run for another iteration.

"progress" seems a nicer name for that.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965/fs: Separate the updating of liveout/livein.

To compute the actual liveout/livein data flow values, we start with
some initial values and apply a fixed-point algorithm until they settle.

Previously, we iterated through all blocks, updating both liveout and
livein together in one pass.  This is awkward, since computing livein
for a block requires knowing liveout for all parent blocks.  Not all
of those parent blocks may have been processed yet.

This patch separates the two.  First, we update liveout for all blocks.
At iteration N of the fixed-point algorithm, this uses livein values
from iteration N-1.  Secondly, we update livein for all blocks.  At
step N, this uses the liveout information we just computed (in step N).

This ensures each computation has a consistent picture of the data,
rather than seeing an random mix of data from steps N-1 and N depending
on the order of the blocks in the CFG data structure.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965/fs: Rename setup_kills() to setup_initial_values().

Although this function currently only initializes the KILL set, it will
soon initialize other data flow sets as well.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965/fs: Create the COPY() set for use in copy propagation dataflow.

This is the "COPY" set from Muchnick's textbook, which is necessary
to do the dataflow algorithm correctly.

v2: Simplify initialization based on Paul Berry's observation that
    out_acp contains exactly what needs to be in the COPY set.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965/fs: Simplify liveout calculation.

Excluding the existing liveout bits is a deviation from the textbook
algorithm.  The reason for doing so was to determine if the value
changed, which means the fixed-point algorithm needs to run for another
iteration.

The simpler way to do that is to save the value from step (N-1) and
compare it to the new value at step N.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965/fs: Use the COPY set in the calculation for liveout.

According to page 360 of the textbook, the proper formula for liveout
is:

CPout(n) = COPY(i) union (CPin(i) - KILL(i))

Previously, we omitted COPY.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965/fs: Properly initialize the livein/liveout sets.

Previously, livein was initialized to 0 for all blocks.  According to
the textbook, it should be the universal set (~0) for all blocks except
the one representing the start of the program (which should be 0).

liveout also needs to be initialized to COPY for the initial block.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965/fs: Drop unnecessary and incorrect liveout initialization.

The previous commit properly initialized liveout.  This previous
(and incorrect) initialization is no longer necessary.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965/fs: Skip the initial block when updating livein/liveout.

The starting block always has livein = 0 and liveout = copy.  Since we
start with real data, not estimates, there's no need to refine it with
the fixed point algorithm.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965/fs: Fully recompute liveout at each step.

Since we start with an overestimation of livein (0xffffffff), successive
steps can actually take away values.  This means we can't simply OR in
new liveout values; we need to recompute it from scratch at each
iteration of the fixed-point algorithm.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965/fs: Fix computation of livein.

Since the initial value for livein is an overestimation (0xffffffff),
it's extremely likely that it will shrink, which means we can't simply
OR in new bits - we need to fully recompute it based on the current
liveout values.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965/fs: Re-enable global copy propagation.

I believe the data flow analysis actually works now, and it should be
safe to re-enable global copy propagation.  It even does things now.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965: Split sampler count variable to be per-stage.

Currently, we only have a single sampler state table shared among all
stages, so we just copy wm.sampler_count into vs.sampler_count.

In the future, each shader stage will have its own SAMPLER_STATE table,
at which point we'll need these separate sampler counts.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965: Un-hardcode border color table from upload_default_color.

When we begin uploading separate sampler state tables for VS and FS,
we won't be able to use &brw->wm.sdc_offset[ss_index].  By passing it in
as a parameter, we push the problem up to the caller.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965: Un-hardcode border color table from update_sampler_state().

Like the previous patch, this simply pushes direct access to brw->wm up
one level in the call chain.  Rather than passing the whole array, we
just pass a pointer to the correct spot in the array, similar to what we
do for the actual sampler state structure.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965: Upload separate per-stage sampler state tables.

Also upload separate sampler default/texture border color entries.

At the moment, this is completely idiotic: both tables contain exactly
the same contents, so we're simply wasting batch space and CPU time.

However, soon we'll only upload data for textures actually /used/ in
a particular stage, which will usually make the VS table empty and
very likely eliminate all redundancy.  This is just a stepping stone.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965: Make upload_sampler_state_table a virtual function.

This allows us to coalesce the brw_samplers and gen7_samplers atoms.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965: Upload separate VS and FS sampler state tables.

Now, each shader stage has a sampler state table that only refers to the
samplers actually used by that problem.  This should make the VS table
non-existant or very small.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>