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 > 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
