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

[Marek Olšák]

Not really. Those two don't use the current framebuffer state, which
makes them not nice to drivers.

The only difference for us would be that radeonsi wouldn't have to
touch and restore some states, and I think the depth could be cleared
fast if the scissor was aligned to 8x8.

Marek

On Fri, Jul 31, 2015 at 10:30 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> You could use pipe clear_render_target and clear_depth_stencil for that.
>
> Roland
>
> Am 31.07.2015 um 22:00 schrieb Marek Olšák:
>> I wouldn't mind moving scissored clears to drivers. u_blitter can do
>> it in the same way after the support is added and drivers will have
>> more control over the states and how they are saved and restored. The
>> catch is the person who will do that will also have to fix it for all
>> drivers.
>>
>> Marek
>>
>> On Fri, Jul 31, 2015 at 8:40 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>> Don't know the situation on other hardware, but at least nvidia
>>> supports both scissors and stencil for its "fast" clear (it's fast at
>>> least in terms of the number of commands submitted and lack of state
>>> changes, no comment on actual execution speed).
>>>
>>> I was thinking of adding a few caps for it.
>>>
>>> On Fri, Jul 31, 2015 at 2:30 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>> Indeed, it is rare. I thought this was hit more often, but apparently
>>>> not. Nevermind.
>>>>
>>>> Marek
>>>>
>>>> On Fri, Jul 31, 2015 at 7:44 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>>>>> 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.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.
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> mesa-dev mailing list
>>>>>> mesa-dev at lists.freedesktop.org
>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=BQIFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=cfRW1YwcNlp92zw8x8jRjmiUHTf_l_PxJZlPVhAQEJM&s=tXQSp9kIbNDFyS4r00lTAftpw9d8oDN6xYLYxVRZTOM&e=
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> mesa-dev mailing list
>>>> mesa-dev at lists.freedesktop.org
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=BQIFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=cfRW1YwcNlp92zw8x8jRjmiUHTf_l_PxJZlPVhAQEJM&s=tXQSp9kIbNDFyS4r00lTAftpw9d8oDN6xYLYxVRZTOM&e=
>