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