clear_render_target and clear_depth_stencil require changing the
framebuffer state, which is more costly than just drawing the quad in
the state tracker. Also, separate color and depth clear isn't very
efficient if you can do both with a single quad.
Adding scissor support to the clear function isn't a bad idea, though
passing a rectangle explicitly would be nicer. I recall VMWare had
some objections to extending the capabilities of clear(), though I
guess they can just emulate what they don't support directly.
Then the other clear functions can be implemented with {
set_framebuffer_state(new); clear(); set_framebuffer_state(old); }.
Marek
On Mon, Dec 2, 2013 at 11:08 PM, Andreas Hartmetz <ahartm...@gmail.com> wrote:
> Hello,
>
> I've been lurking for a while, this seems to be my first post.
>
> While trying to make some "easy" (ha) improvements in radeonsi I looked
> around in all the surrounding code to get a good picture of how things
> work. So I noticed something:
> All the Gallium drivers need to implement clear_depth_stencil() and
> clear_render_target() from pipe_context. Those implementations are
> generally using little to no acceleration, just making sure that
> there's any implementation at all. Still, it's quite a few lines over
> all the drivers. The two methods in question were introduced for
> Direct3D, which has no in-tree state tracker anymore, and for scissored
> clearing in OpenGL. But scissored clearing is already implemented as a
> fallback using quad drawing in the OpenGL state tracker (st_cb_clear.c,
> clear_with_quad()) in pretty much the same way as the unoptimized paths
> in drivers.
>
> So, the question arises: Does anybody still use those functions, maybe
> VMware in some out-of-tree code?
> If not I suggest removing them and I'd send patches to do that.
> Alternatively, they could be reduced to do just scissored clearing,
> and the OpenGL state tracker could call that in the hope that some GPU
> will have an optimized way to do it (how realistic is that? I have not
> looked at all the GPU drivers...).
>
> Cheers,
> Andreas
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
