summaryrefslogtreecommitdiffstats
path: root/src/mesa/main/streaming-load-memcpy.h
diff options
context:
space:
mode:
authorAlejandro Piñeiro <[email protected]>2019-07-29 13:06:44 +0200
committerAlejandro Piñeiro <[email protected]>2019-07-30 12:05:23 +0200
commitcda4c628936ed85c2cace082efc848721a123246 (patch)
tree36cffa48f663e27277f62c15bbff751131f38b82 /src/mesa/main/streaming-load-memcpy.h
parent45638e14fb9d4ca66de12fbbf2aba35c3665341e (diff)
v3d: take into account separate_stencil when checking if stencil should be cleared
In most cases this is not needed because the usual is that when a separate stencil is written, the parent resource is also written. This is needed if we have a separate stencil, no depth buffer, and the source and destination is the same, as in that case the stencil can be updated, but not the parent source (like if you are blitting only the stencil buffer). On that situation, the following access to the stencil buffer would clear the stencil buffer (so overwritting the previous blitting) cleared because the parent source has v3d_resource.writes to 0. As far as I see, that situation only happens with the GL_DEPTH32F_STENCIL8 format. Note that one alternative would consider that if the separate_stencil has been written, the parent should also be considered written (and update its "writes" field accordingly). But I found this patch more natural. Fixes the following piglit tests: spec/arb_depth_buffer_float/fbo-stencil-gl_depth32f_stencil8-blit spec/arb_depth_buffer_float/fbo-stencil-gl_depth32f_stencil8-copypixels the latter regressed when internally glCopyPixels implementation started to use blitting. So: Fixes: 131d40cfc91f ("st/mesa: accelerate glCopyPixels(STENCIL)") Reviewed-by: Eric Anholt <[email protected]>
Diffstat (limited to 'src/mesa/main/streaming-load-memcpy.h')
0 files changed, 0 insertions, 0 deletions