[Mesa-dev] shader stencil export v(x+1)
airlied at gmail.com
Fri Oct 8 23:09:00 PDT 2010
On Sat, Oct 9, 2010 at 2:15 AM, Brian Paul <brianp at vmware.com> wrote:
> On 10/07/2010 12:42 AM, Dave Airlie wrote:
>> Okay I've pushed another iteration of the gallium + mesa + softpipe +
>> r600g changes for accelerated stencil rendering to
>> Quick patch summary by area: I've marked two mesa ones as needing some
>> competent review.
>> add TGSI stencil semantic + capability
>> add support for S8X24_USCALED, X24S8_USCALED,
>> add sampler support for S8,
>> and format support only for X32_S8X24_USCALED
>> add FRAG_RESULT_STENCIL
>> improve the texstore handlers for S8Z24 and Z24S8 (!!!!please review!!!!)
> One question here: why does the code try to preserve any existing
> depth/stencil bits in the target texture buffer? For example, if we're
> putting depth values into a Z+Stencil texture, why do the stencil bits
> matter? Or another way: under what circumstance would we try to merge
> separate depth/stencil images into one Z+Stencil texture?
The old code did this for GL_DEPTH_COMPENENT uploads, it kept the
so I decided to keep it consistent and if you upload GL_STENCIL_INDEX
you get to keep
the depth pieces, though I'm not really sure if that is every going to
happen in reallife,
but since I preferred just making the code generic it didn't seem like
a major overhead.
>> add a texstore handler for S8 (!!!!! please review !!!!!)
> The inner-most for-loop could be a memcpy().
> I'm OK with merging this. I'm sure we can fix any regressions that might
> pop up.
Cool I'll merge it early next week if nothing else pops up, just want
to make my dumb piglit test a bit more useful.
More information about the mesa-dev