Age | Commit message (Collapse) | Author |
|
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
as with constants
|
|
|
|
This avoids issues with dereferencing stale cliprects around intel_draw_buffer
time. Additionally, take advantage of cliprects staying constant for FBOs and
DRI2, and emit cliprects in the batchbuffer instead of having to flush batch
each time they change.
|
|
Plus add assertions to check status, alignment, etc.
|
|
This could be a lot better, but already makes for better code.
|
|
This is required for threads to be spawned with correctly sized GRF
register blocks.
|
|
Doesn't seem to be needed and fixes compilation with SDK 3.1 beta.
|
|
|
|
|
|
|
|
|
|
allows glReadPixels to work correctly on cell now and makes conformance tests that use pixel compares useable.
|
|
|
|
|
|
Previously, we were trying to pass a name to the GEM GET_TILING_IOCTL,
which needs a handle, and failing. None of our buffers were tiled yet, but
they will be at some point with DRI2 and UXA.
|
|
|
|
|
|
(thanks Eric).
|
|
This ensures there is an unfilled batchbuffer used for emitting states again. Partial fix for #17964.
|
|
Use _mesa_copy_rect instead of BLT operation if dri_bufmgr_check_aperture_space
still fails after flushing batchbuffer. Partial fix for #17964.
|