As far as I can read in the docs, VS threads can be 1:1 with the pairs of
VUE handles allocated for them. Also, G4X can run twice as many threads as
before (though we won't unless the we bump the preferred URB entries for VS).
We were dividing the number of URB entries by two to get number of threads,
which looks suspiciously like a copy'n'paste-o from brw_vs_state.c. Also, the
maximum number of threads is 24, not 12.
The clip thread could potentially deadlock when processing tristrips since
being moved back to dual-thread mode, as the two threads could each have 4 VUEs
referenced and not be able to allocate another one since SF processing
wasn't able to continue (needing 5 entries before it freed 2).
In constrained URB mode, similar deadlock could even have occurred with
polygons (so we cut back max_threads if we can't handle it any primitive type).
Fixed a boneheaded error in the generation of SPU code that calculates
the results of the stencil test. Basically, all the greater than/less than
calculations were exactly inverted: they were coded as though the
given comparison took the stencil value as a left-hand operand and the
reference value as a right-hand operand, but the actual semantics always
put the reference as the left-hand operand and the stencil as the right-hand
operand.
With this fix, tests/dinoshade runs, as do all the other Mesa tests
and samples that use stencil (and that don't use texture formats
unsupported by Cell).
With these changes, the tests/stencil_twoside test now works.
- Eliminate blending from the stencil_twoside test, as it produces an
unneeded dependency on having blending working
- The spe_splat() function will now work if the register being splatted
and the destination register are the same
- Separate fragment code generated for front-facing and back-facing
fragments. Often these are the same; if two-sided stenciling is on,
they can be different. This is easier and faster than generating
code that does both tests and merges the results.
- Fixed a cut/paste bug where if the back Z-pass stencil operation
were different from all the other operations, the back Z-fail
results were incorrect.
This ensures all batchbuffers have a same cliprect mode after calling
_intel_batchbuffer_flush even if there aren't invalid commands in the
current batch buffer. (fix bug#18362).
See bug 18445.
When getting array results, __glXReadReply() always reads a multiple of
four bytes. This can cause writing to invalid memory when 'n' is not a
multiple of four.
Special-case the glAreTexturesResident() functions now.
To fix the bug, we use a temporary buffer that's a multiple of four bytes
in length.
NOTE: this commit also reverts part of commit 919ec22ecf
(glx/x11: Added some #ifdef GLX_DIRECT_RENDERING protection) which
directly edited the indirect.c file rather than the python generator!
I'm not repairing that issue at this time.
Eric Anholt
Kristian Høgsberg
Robert Ellison
Brian Paul
Michal Krol
Hanno Böck
Xiang, Haihao
Pekka Paalanen
Zack Rusin