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(C
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 ca
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 wrote:
>
> So, if this provides a significant performance differenc
I'll add a cap then.
The fast clear is a technique that doesn't actually clear memory.
Instead, it postpones clearing until later time in hope that the
cleared area will be overdrawn anyway and no clearing will have to be
done. The idea is to have a clear/non-cleared 1-bit flag per tile.
Instead o
I agree that this seems to be pretty bad if you have interleaved
depth/stencil buffers (and no way to fast-clear them independently),
though I wonder which apps actually hit this? It looks to me like the
conditions you'd hit quad clear with one of depth/stencil but normal
clear with the other are f
What you mean by "fast clear"?
llvmpipe depth-stencil buffers are interleaved, and AFAICT partial clears will
be done with quads. In other words, this will make llvmpipe slower.
In truth, this will all drivers with interleaved z/s bufferss slower. That is,
this is optimizing for some drivers
It will only be worse for combined Z-stencil buffers if Z and
stencil are interleaved, and if SW rasterizers don't support any kind
of fast clear.
Marek
On Fri, Dec 13, 2013 at 3:21 PM, Jose Fonseca wrote:
> This is worse for SW renderers...
>
> Jose
>
> - Original Message -
>> From: Mar
This is worse for SW renderers...
Jose
- Original Message -
> From: Marek Olšák
>
> ---
> src/mesa/state_tracker/st_cb_clear.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_clear.c
> b/src/mesa/state_tracker/st_cb_cl
From: Marek Olšák
---
src/mesa/state_tracker/st_cb_clear.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_clear.c
b/src/mesa/state_tracker/st_cb_clear.c
index 887e58b..46f2f8d 100644
--- a/src/mesa/state_tracker/st_cb_clear.c
+++ b/
