Age | Commit message (Collapse) | Author |
|
|
|
The swizzle mask for such variables wasn't set up properly.
|
|
|
|
|
|
Mainly for debugging purposes for now.
|
|
|
|
This cuts one MOV out when setting a zero header.
|
|
The mobile and desktop chipsets are the same, and having them separate is
more typing and more chances to screw up.
|
|
Also, add a comment explaining what brw->urb.constrained tries to do.
|
|
|
|
|
|
Use pipe_buffer_reference instead.
|
|
|
|
|
|
|
|
|
|
This cuts one MOV out when setting a zero header.
|
|
The mobile and desktop chipsets are the same, and having them separate is
more typing and more chances to screw up.
|
|
Also, add a comment explaining what brw->urb.constrained tries to do.
|
|
Conflicts:
src/mesa/shader/slang/library/slang_vertex_builtin_gc.h
|
|
|
|
This fixes a function inlining bug involving vars declared inside loop bodies.
|
|
|
|
|
|
|
|
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>
|
|
|
|
|
|
|
|
|
|
GL_COLOR_INDEX mode is just like other normal formats (that is, not
depth/stencil) and is uploaded fine by TexImage.
|
|
|
|
(Only in fragment shaders, so far. Support for NOISE3 and NOISE4 to come.)
|
|
This is required for scatter writes in destination regions to work.
|
|
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.
|
|
|
|
temps. This avoids useless writes of temporary results.
|
|
|
|
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.
|
|
blocks during st_readpixels due to a flush wait not happening in order to allow any previous rendering to complete.
|
|
|
|
|
|
|
|
|
|
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.
|
|
functions in mesa/main/mm.c
|
|
|
|
Scalar calls only use the X component of the src regs and smear the
result across the dest register's X/Y/Z/W.
|
|
|
|
That's the last of the ARB_v_p opcodes, except for ARL.
|