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 of clearing the renderbuffer, you just clear the flags and
save the clear value in the renderbuffer structure, because that's the
only way to remember it. If the tile state is "non-cleared", the tile
contains valid pixels. If the tile state is "cleared", the tile
contains garbage and any reads from the renderbuffer should return the
saved clear value (e.g. for blending or depth/stencil testing).
If you render a primitive and the primitive covers an entire tile, you
draw new pixels and set the tile state to non-cleared (= the tile has
valid pixels). In this case you avoid clearing entirely. If there is a
primitive edge intersecting a tile, you draw new pixels for that
primitive and then you also have to write the saved clear value to the
other pixels which are outside of the primitive. After that, you also
set the tile state to non-cleared (= the tile has valid pixels).
That's how you do rendering and avoid clearing. If you have to map the
renderbuffer or put it on the screen, you must clear the tiles which
are still in the cleared state (= the tile has invalid pixels) by
explicitly writing the clear value to those tiles. This also implies
that you can have only one clear value per renderbuffer.
Marek
On Fri, Dec 13, 2013 at 5:46 PM, Jose Fonseca <jfons...@vmware.com> wrote:
> 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 at expense of others which might have
> interleaved depth-stencil buffer. The very fact that it is worthwhile doing
> this change for your gpu means that it must be worthwhile for others to leave
> it as it was...
>
> 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.
>
> Jose
>
> ----- Original Message -----
>> 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 <jfons...@vmware.com> wrote:
>> > This is worse for SW renderers...
>> >
>> > Jose
>> >
>> > ----- Original Message -----
>> >> From: Marek Olšák <marek.ol...@amd.com>
>> >>
>> >> ---
>> >> 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/src/mesa/state_tracker/st_cb_clear.c
>> >> @@ -476,14 +476,16 @@ st_Clear(struct gl_context *ctx, GLbitfield mask)
>> >> }
>> >> }
>> >>
>> >> - /*
>> >> - * If we're going to use clear_with_quad() for any reason, use it for
>> >> - * everything possible.
>> >> + /* 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. Even if there is
>> >> + * a combined depth-stencil buffer, the depth and stencil components
>> >> + * may be stored separately internally.
>> >> */
>> >> if (quad_buffers) {
>> >> - quad_buffers |= clear_buffers;
>> >> clear_with_quad(ctx, quad_buffers);
>> >> - } else if (clear_buffers) {
>> >> + }
>> >> + if (clear_buffers) {
>> >> /* We can't translate the clear color to the colorbuffer format,
>> >> * because different colorbuffers may have different formats.
>> >> */
>> >> --
>> >> 1.8.3.2
>> >>
>> >> _______________________________________________
>> >> mesa-dev mailing list
>> >> mesa-dev@lists.freedesktop.org
>> >> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=cvIgdPYPFAOCEZnN3p40o7cbw0cTfSQzytP%2Byju9mDI%3D%0A&s=b1c126addd7be0ac34d91039bb019dabb14c976597b451daa14f440755d95f14
>> >>
>>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
