Quoting section 11.3.10, paragraph 10.2 of the 965PRM:
10.2. If ExecSize is 1, dst.HorzStride must not be 0. Note that this is
relaxed from rule 10.1.2. Also note that this rule for destination
horizontal stride is different from that for source as stated in
rule #7.
GM45 gets very angry when rule 10.2 is violated.
Patch 58dc8b7 (i965: support destination horiz strides in align1 access mode)
added support for additional horizontal strides in the ExecSize 1 case, but
failed to notice that mesa occasionally re-purposes a register as a
temporary destination, even though it was constructed as a repeating source
with HorzStride = 0.
While, ideally, we should probably fix the code using these register
specifications, this patch simply rewrites them to use HorzStride 1 as the
pre-58dc8b7 code did.
Signed-off-by: Keith Packard <keithp@keithp.com>
The Cell stencil tests were completely ignoring the stencil value mask.
Now the original code paths are still used if the stencil value mask
is all 1s; but code to use the mask for the stencil value and reference
value comparisons is now emitted if the mask is not all 1s.
Two definitive bugs in stenciling were fixed.
The first, reversed registers in the generated Select Bytes (selb)
instruction, caused the stenciling INCR and DECR operations to
fail dramatically, putting new values in where old values were
supposed to be and vice versa.
The second caused stencil tiles to not be read and written from
main memory by the SPUs. A per-spu flag, spu.read_depth, was used
to indicate whether the SPU should be reading depth tiles, and was set
only when depth was enabled. A second flag, spu.read_stencil, was
set when stenciling was enabled, but never referenced.
As stenciling and depth are in the same tiles on the Cell, and there
is no corresponding TAG_WRITE_TILE_STENCIL to complement
TAG_WRITE_TILE_COLOR and TAG_WRITE_TILE_Z, I fixed this by
eliminating the unused "spu.read_stencil", renaming "spu.read_depth"
to "spu.read_depth_stencil", and setting it if either stenciling or
depth is enabled.
I also added an optimization to the fragment ops generation code,
that avoids calculating stencil values and/or stencil writemask
when the stencil operations are all KEEP.
Was 32, now 5. The param is expressed as a power of two exponent.
The net effect is that the alignment was a no-op on X86 but on PPC we
always got the same memory address everytime rtasm_exec_malloc() was called.
Was 32, now 5. The param is expressed as a power of two exponent.
The net effect is that the alignment was a no-op on X86 but on PPC we
always got the same memory address everytime rtasm_exec_malloc() was called.
Previously, since my check_aperture API change, we would check each piece of
state against the batchbuffer individually, but not all the state against the
batchbuffer at once. In addition to not being terribly useful in assuring
success, it probably also increased CPU load by calling check_aperture many
times per primitive.
