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 <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
>>>> 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@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
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
