[Mesa-dev] [PATCH 1/9] st/mesa: always prefer pipe->clear over clear_with_quad

Roland Scheidegger sroland at vmware.com
Fri Dec 13 10:37:17 PST 2013


I agree that this seems to be pretty bad if you have interleaved
depth/stencil buffers (and no way to fast-clear them independently),
though I wonder which apps actually hit this? It looks to me like the
conditions you'd hit quad clear with one of depth/stencil but normal
clear with the other are fairly obscure (partial stencil write mask, or
rbs with different size and scissor set in a way so the scissor bounds
hit one but not the other). Which of course begs the question where that
change made a difference in the first place.

Roland

Am 13.12.2013 17:46, schrieb Jose Fonseca:
> What you mean by "fast clear"?
> 
> llvmpipe depth-stencil buffers are interleaved, and AFAICT partial clears will be done with quads.  In other words, this will make llvmpipe slower.
> 
> In truth, this will all drivers with interleaved z/s bufferss slower.  That is, this is optimizing for some drivers at expense of others which might have interleaved depth-stencil buffer.  The very fact that it is worthwhile doing this change for your gpu means that it must be worthwhile for others to leave it as it was...
> 
> So, if this provides a significant performance difference, then I think the only option to have everybody happy is to have cap to choose the optimal behavior.
> 
> Jose
> 
> ----- Original Message -----
>> 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 <jfonseca at vmware.com> wrote:
>>> This is worse for SW renderers...
>>>
>>> Jose
>>>
>>> ----- Original Message -----
>>>> From: Marek Olšák <marek.olsak at 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 at lists.freedesktop.org
>>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=cvIgdPYPFAOCEZnN3p40o7cbw0cTfSQzytP%2Byju9mDI%3D%0A&s=b1c126addd7be0ac34d91039bb019dabb14c976597b451daa14f440755d95f14
>>>>
>>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=eR6SFsBDzw4W2%2Bl2SHXk12%2Fvz46iKWv1ohQNKFy4yiY%3D%0A&s=ad761b9846d926b7e49bdd0847c1846c0ae4f9f7002a4217a0c2a552f29b6b14
> 


More information about the mesa-dev mailing list