[Mesa-dev] [PATCH 1/9] st/mesa: always prefer pipe->clear over clear_with_quad

[Marek Olšák]

I still would like to have this for color and combined depth-stencil
clears. If either attachment can use pipe->clear, let's use it. I
think the only disagreement is over what should happen if there is a
partial stencil write mask. The following cases are still okay, aren't
they?

1)

pipe->clear(COLOR0);
clear_with_quad(COLOR1);

2)

pipe->clear(COLOR0 | DEPTH | STENCIL);
clear_with_quad(COLOR1);

3)

pipe->clear(COLOR0);
clear_with_quad(COLOR1 | DEPTH | STENCIL);


The point is pipe->clear is almost free on drivers which optimize it.
clear_with_quad isn't.

Marek

On Wed, Dec 18, 2013 at 1:04 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
> If this is such a corner case, that's not worth the diligence, then I think it might be better to drop the change.
>
> If it was just software rendering (llvmpipe) I wouldn't mind, as bottlenecks are elsewhere anyway.  My concern is more of principle here: I'm assuming there is other hardware we care about that has interleaved depth stencil (*), and whatever the separate depth-stencil hardware has to gain with this change, the former stands to lose.  And this is the sort of precedent what I want to prevent.
>
> If it was regressing hardware nobody cares for the sake of hardware that people do, I'd be fine.  What I really don't want is developer A commiting a change that makes driver X faster but Y slower, then developer B commits a change that makes Y faster and X slower, and we go around in circles instead of moving all forward.
>
> But if I'm wrong -- nobody else cares -- I won't object further.
>
> Jose
>
> (*) I only recall AMD having them separate, so I assume e.g., NVIDIA has them interleaved.  And I'm not sure if all have use the fast clear optimization.
>
> ----- Original Message -----
>> José, is it really worth adding a new cap? The only way to hit both
>> pipe->clear and clear_with_quad for depth and stencil, respectively,
>> is to have a partial stencil writemask.
>>
>> Marek
>>
>> On Fri, Dec 13, 2013 at 5:46 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>> >
>> > So, if this provides a significant performance difference, then I think the
>> > only option to have everybody happy is to have cap to choose the optimal
>> > behavior
>>