Actually, since the code says it can only happen with a non-full stencil mask, isn't clearing depth/stencil with a non-full stencil mask incredibly rare?
Roland Am 31.07.2015 um 18:51 schrieb Roland Scheidegger: > I don't think that's quite true in general. > For gpus which have combined ds buffers I can'see why you'd wanted to do > separate clears for depth and stencil in this case (i.e. doing > pipe->clear for depth, then draw a quad for clearing stencil). > At least for "simple" hw like llvmpipe which don't have special depth > clear, this clearly seems to be much worse (you have to go through the > memory twice). > > I vaguely remember something like this being proposed some time ago with > some discussion that not the same thing is optimal depending on the > hw... I don't think though there's anything at the moment where you > could figure out what is better. > > Roland > > > > Am 31.07.2015 um 17:15 schrieb Marek Olšák: >> From: Marek Olšák <marek.ol...@amd.com> >> >> A lot of GPUs allocate separate depth and stencil buffers, so clearing them >> together doesn't make much sense. If some GPUs don't allocate separate >> depth & stencil, it's still beneficial to clear the HiZ / HiS information >> for only one of the two. >> --- >> src/mesa/state_tracker/st_cb_clear.c | 9 --------- >> 1 file changed, 9 deletions(-) >> >> diff --git a/src/mesa/state_tracker/st_cb_clear.c >> b/src/mesa/state_tracker/st_cb_clear.c >> index 137fac8..1e404a2 100644 >> --- a/src/mesa/state_tracker/st_cb_clear.c >> +++ b/src/mesa/state_tracker/st_cb_clear.c >> @@ -515,15 +515,6 @@ st_Clear(struct gl_context *ctx, GLbitfield mask) >> } >> } >> >> - /* Always clear depth and stencil together. >> - * This can only happen when the stencil writemask is not a full mask. >> - */ >> - if (quad_buffers & PIPE_CLEAR_DEPTHSTENCIL && >> - clear_buffers & PIPE_CLEAR_DEPTHSTENCIL) { >> - quad_buffers |= clear_buffers & PIPE_CLEAR_DEPTHSTENCIL; >> - clear_buffers &= ~PIPE_CLEAR_DEPTHSTENCIL; >> - } >> - >> /* Only use quad-based clearing for the renderbuffers which cannot >> * use pipe->clear. We want to always use pipe->clear for the other >> * renderbuffers, because it's likely to be faster. >> > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev