[Mesa-dev] [PATCH] st/mesa: don't try to clear depth and stencil together in glClear fallback

[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.olsak at 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.
>