Well you could detect if it belongs to the current fb, in which case you wouldn't need to change the fb. And if not (which shouldn't happen with OpenGL state tracker admittedly) then if you wouldn't have that function the state tracker would need to swap out the fb instead, which isn't going to be cheaper anyway. That said, if drivers don't want to implement this we can make it optional I guess. I don't actually know if using clears that way (with non-bound fb) is common, but if it is we don't want to deal with that in the state tracker. (For llvmpipe, that would mean flushing out the tiles to be able to exchange the fb for nothing which definitely can be expensive).
Roland Am 03.12.2013 01:14, schrieb 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 <srol...@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@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=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=0coW08nT6r7ZLjKHd4e0rrZOoRhtnqwdUtObq6NKdsQ%3D%0A&s=32b0fceb22648dbafa5b4bc73e293977be516b01e6b5f0a8dd9b5998e57983b6 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
