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