Previously all drivers were in twosided mode since they checked for
stencil.enable[1] flag which was a copy of stencil.enable[0]. Note that drivers
should not reference stencil[1] state (other than the enable) if twosided
stenciling is disabled (for now the stencil state is still copied but for
instance clear_with_quads won't provide useful values in there).
Also, use _TestTwoSide instead of TestTwoSide since results would be
bogus otherwise if using APIs with implicit two side stencil enable
(i.e. core ogl 2.0).
This handles the case where bypass_vs is set, but vertices need to go
through the pipeline for some reason - eg unfilled polygon mode.
Demonstrates how to drive the pipeline from inside one of these things.
Leaving it until 'run' is bad as the primitive is pretty much state
for some drivers and so needs to get set early. In some drivers
this is used to determine things like vertex format, etc -- by the
time we get to 'run', it's too late to change this.
Use this to set up hardware rasterization (if your hardware can
do it) or otherwise turn on various tweaks in the draw module.
Currently only hooked up to point biasing code.
- Reduce the number of changes to the normal vertex ordering
- Assume that the hardware knows how to do this in the standard case.
- Add support to the passthrough vcache path.
Make sure the struct pipe_fence_handle* we point st_flush() to is initialized
to NULL, so winsys->fence_reference() doesn't try to unreference a random
struct pipe_fence_handle* pointer.
Also free buffers as soon as possible.
This short term fix corrects the fenced list behavior but it will impact on performance.
The long term fix is probably replace the linked list (legacy from the bufpool code) by
a binary tree.
"Off" bits get stored as texel=0xff and "on" bits get stored as texel=0x0.
Then use KIL -tmp to kill the off bits and keep the on bits.
This shortens the fragment program by two instructions.
