[Mesa-dev] [PATCHv2 1/3] gallium: add interface to clear buffers

Marek Olšák maraeo at gmail.com
Wed Mar 26 19:04:54 PDT 2014


On Wed, Mar 26, 2014 at 4:30 AM, Roland Scheidegger <sroland at 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.

Marek


More information about the mesa-dev mailing list