[Mesa-dev] Anybody still need clear_depth_stencil() or clear_render_target()?

[Marek Olšák]

The glClearBuffer functions don't change the framebuffer state in most
cases, but the clear_render_target function does, so using it is out
of the question.

Yeah, the implementation of glClearBuffer seems to be incomplete.

Marek

On Tue, Dec 3, 2013 at 12:54 AM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 02.12.2013 23:08, schrieb Andreas Hartmetz:
>> 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...).
>>
>
> Yes we have some internal use for them as they indeed map well to d3d
> semantics.
> That said the idea was they could also be used for the GL 3.0 single
> color buffer attachment clears (the ClearBuffer commands). Looks though
> like everyone (gallium and also i965 driver) just drops that argument on
> the floor and clears all (color) attachments simultaneously always
> anyway (?!?). Assuming I'm not missing anything and this is indeed a bug
> then to fix that you'd either need to extend the gallium "ordinary"
> clear semantics to be able to indicate the color attachment to clear, or
> do a quad clear, or create a new fb for clearing, or just use these
> commands... (Well ok only for render_target not depth_stencil since
> there's no problem with multiple buffers there.)
>
> Roland
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev