CELL: fix several stencil problems

This small set of changes repairs several different stenciling problems;
now redbook/stencil also runs correctly (and maybe others - I haven't
checked everything yet).

- The number of instructions that had been allocated for fragment ops
  used to be 64 (in cell/common.h).  With complicated stencil use, we
  managed to get up to 93, which caused a segfault before we noticed
  we'd overran our memory buffer.  It's now been bumped to 128,
  which should be enough for even complicated stencil and fragment op
  usage.

- The status of cell surfaces never changed beyond the initial
  PIPE_SURFACE_STATUS_UNDEFINED.  When a user called glClear()
  to clear just the Z buffer (but not the stencil buffer), this caused
  the check_clear_depth_with_quad() function to return false (because
  the surface status was believed to be undefined), and so the device
  was instructed to clear the whole buffer (including the stencil buffer),
  instead of correctly using a quad to clear just the depth, leaving the
  stencil alone.

  This has been fixed similarly to the way the i915 driver handles
  the surface status: during cell_clear_surface(), the status is
  set to PIPE_SURFACE_STATUS_DEFINED.  Then a partial buffer clear is
  handled with a quad, as expected.  Note that we are *not* using
  PIPE_SURFACE_STATUS_CLEAR (also similar to the i915); technically,
  we should be setting the surface status to CLEAR on a clear, and
  to DEFINED when we actually draw something (say on cell_vbuf_draw()),
  but it's difficult to figure out exactly which surfaces are affected
  by a cell_vbuf_draw(), so for now we're doing the easy thing.

- The fragment ops handling was very clever about only pulling out the
  parts of the Z/stencil buffer that it needed for calculations;
  but this failed when only part of the buffer was written, because
  the part that was never pulled out was inadvertently cleared.

  Now all the data from the combined Z/stencil buffer is pulled out,
  just so the proper values can be recombined later and written back
  to the buffer correctly.  As a bonus, the fragment op code generation
  is simplified.

0 files changed, 0 insertions, 0 deletions