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

[Ilia Mirkin]

Unless that person sticks it behind a pipe cap :) Which is how *this*
person was planning on doing it... nouveau doesn't use u_blitter by
the way.

  -ilia

On Fri, Jul 31, 2015 at 4:00 PM, Marek Olšák <maraeo at gmail.com> wrote:
> 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
>>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>>>
>>>>
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev