----- Original Message ----- > On Wed, Mar 26, 2014 at 4:30 AM, Roland Scheidegger <srol...@vmware.com> > wrote: > > Am 26.03.2014 03:29, schrieb Marek Olšák: > >> My reasoning was that it would be better to specify a raw clear value > >> and clear value size for buffers, which are always untyped, and > >> pipe_color_union for textures, which are always typed, so that drivers > >> can easily implement the texture clearing on top of > >> pipe_context::clear. > >> > >> I also suggested that clear_render_target and clear_depth_stencil > >> should be removed in favor of a new function clear_texture(pipe, > >> resource, level, box, pipe_color_union). For depth-stencil, we can > >> assume that the first component of the clear color is a floating-point > >> depth value and the second component is an unsigned integer stencil > >> value. > > This could not clear only depth or stencil, though. > > Clear is just a mess why couldn't the apis agree a bit more what is > > useful... > > So d3d10 can only clear render target / depth stencil views, meaning > > your resrouces need the bind_render_target flag (not that drivers > > actually usually enforce this for rendering since it breaks mesa state > > tracker in a couple of places due to this being not required in general > > and hard to guess in GL). You cannot clear only parts (or rather, you > > can clear individual layers and such by creating a different view, but > > not specify coords). You can however clear only depth or stencil. > > And you cannot clear buffers (well you can if you make them render > > target bindable but this has severe limitations and isn't something > > you'd do just so you can clear them). > > GL OTOH doesn't require the resources to be renderable for clearing to > > work, doesn't allow to clear only depth/stencil but does allow a box. > > There's also another problem with the proposed parameters for d3d10, the > > format of the resource could be different to that you'd actually want to > > use for clearing (for typeless resources). > > Adding the format parameter is not a problem. It would also allow > depth-only or stencil-clear by setting Z24X8 or X24S8, respectively. > > Regarding non-renderable textures, well, RGB9_E5 is the only > non-renderable GL format on Radeon and we could easily clear that as > R32_UINT. Radeon drivers already change texture formats to support > fully-accelerated resource_copy_region and they will do so for > clearing as well. You can always use a software fallback if you have > no other option. > > Some of the GL 4.x stuff will be a bigger mess, and there are also fun > things like GL_ARB_bindless_texture.
Having a clear_resource, with all necessary parameters so it can superceed clear_render/depth_stencil view, seems a sensible thing to do FWIW. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
