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