summaryrefslogtreecommitdiff
path: root/common.py
diff options
context:
space:
mode:
authorRobert Ellison <papillo@tungstengraphics.com>2008-11-07 11:29:07 -0700
committerRobert Ellison <papillo@tungstengraphics.com>2008-11-07 11:29:35 -0700
commitb493fdd7e333b9a94176a603009643326a538690 (patch)
tree8dac009347e513e07d5e32aff31b86ad9659f9b9 /common.py
parent18a4cdcfc00a7a936c4a2fd0db27edba14ae5cd7 (diff)
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.
Diffstat (limited to 'common.py')
0 files changed, 0 insertions, 0 deletions