It will only be worse for combined Z-stencil buffers if Z and
stencil are interleaved, and if SW rasterizers don't support any kind
of fast clear.
Marek
On Fri, Dec 13, 2013 at 3:21 PM, Jose Fonseca <jfons...@vmware.com> wrote:
> This is worse for SW renderers...
>
> Jose
>
> ----- Original Message -----
>> From: Marek Olšák <marek.ol...@amd.com>
>>
>> ---
>> src/mesa/state_tracker/st_cb_clear.c | 12 +++++++-----
>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/mesa/state_tracker/st_cb_clear.c
>> b/src/mesa/state_tracker/st_cb_clear.c
>> index 887e58b..46f2f8d 100644
>> --- a/src/mesa/state_tracker/st_cb_clear.c
>> +++ b/src/mesa/state_tracker/st_cb_clear.c
>> @@ -476,14 +476,16 @@ st_Clear(struct gl_context *ctx, GLbitfield mask)
>> }
>> }
>>
>> - /*
>> - * If we're going to use clear_with_quad() for any reason, use it for
>> - * everything possible.
>> + /* 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. Even if there is
>> + * a combined depth-stencil buffer, the depth and stencil components
>> + * may be stored separately internally.
>> */
>> if (quad_buffers) {
>> - quad_buffers |= clear_buffers;
>> clear_with_quad(ctx, quad_buffers);
>> - } else if (clear_buffers) {
>> + }
>> + if (clear_buffers) {
>> /* We can't translate the clear color to the colorbuffer format,
>> * because different colorbuffers may have different formats.
>> */
>> --
>> 1.8.3.2
>>
>> _______________________________________________
>> 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
