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

[Ilia Mirkin]

On Thu, Mar 27, 2014 at 12:16 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Thu, Mar 27, 2014 at 11:35 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
>>
>>
>> ----- Original Message -----
>>> 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.
>>
>> Having a clear_resource, with all necessary parameters so it can superceed clear_render/depth_stencil view, seems a sensible thing to do FWIW.
>
> Just to clarify -- is this a vote against my current implementation of
> ARB_clear_buffer_object acceleration (which adds a ->clear_buffer
> call), or a comment on how you'd like to see ARB_clear_texture
> acceleration implemented?

I haven't heard back on this, so I'm assuming that everyone is fine
with my proposed patches as-is. I have a R-b from Marek for the
generic bits, so unless I hear otherwise by tonight, I'll be pushing
that out.

>
> If the latter, I'm concerned that there will be drivers that can clear
> RT's but not random textures. This shouldn't be an issue for
> nv50/nvc0, but I'm much less familiar with what else is out there.
> FWIW, the way that'd be done on nv50/nvc0 is by cheating -- there are
> actually a bunch of formats that can be used for texturing but not
> rendering. But the clear mechanism is just a glorified memset, so we
> can fake the formats as long as they're the right number of bytes.
>
>   -ilia