[Mesa-dev] [PATCHv2 1/3] gallium: add interface to clear buffers
Roland Scheidegger
sroland at vmware.com
Tue Mar 25 20:30:11 PDT 2014
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).
Roland
>
> Marek
>
> On Wed, Mar 26, 2014 at 1:17 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Tue, Mar 25, 2014 at 7:57 PM, Brian Paul <brianp at vmware.com> wrote:
>>> On 03/25/2014 05:23 PM, Ilia Mirkin wrote:
>>>>
>>>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>>>> ---
>>>>
>>>> v1 -> v2: add docs section to context.rst
>>>>
>>>> src/gallium/docs/source/context.rst | 5 +++++
>>>> src/gallium/include/pipe/p_context.h | 11 +++++++++++
>>>> 2 files changed, 16 insertions(+)
>>>>
>>>> diff --git a/src/gallium/docs/source/context.rst
>>>> b/src/gallium/docs/source/context.rst
>>>> index 8e14522..efa2a1c 100644
>>>> --- a/src/gallium/docs/source/context.rst
>>>> +++ b/src/gallium/docs/source/context.rst
>>>> @@ -218,6 +218,11 @@ is is also possible to only clear one or the other
>>>> part). While it is only
>>>> possible to clear one surface at a time (which can include several
>>>> layers),
>>>> this surface need not be bound to the framebuffer.
>>>>
>>>> +``clear_buffer`` clears a PIPE_BUFFER resource with the specified clear
>>>> value
>>>> +(which may be multiple bytes in length). Logically this is a memset with
>>>> a
>>>> +multi-byte element value starting at offset bytes from resource start,
>>>> going
>>>> +for size bytes. It is guaranteed that size % clear_value_size == 0.
>>>> +
>>>>
>>>> Drawing
>>>> ^^^^^^^
>>>> diff --git a/src/gallium/include/pipe/p_context.h
>>>> b/src/gallium/include/pipe/p_context.h
>>>> index fe3045a..bf27285 100644
>>>> --- a/src/gallium/include/pipe/p_context.h
>>>> +++ b/src/gallium/include/pipe/p_context.h
>>>> @@ -332,6 +332,17 @@ struct pipe_context {
>>>> unsigned dstx, unsigned dsty,
>>>> unsigned width, unsigned height);
>>>>
>>>> + /**
>>>> + * Clear a buffer. Runs a memset over the specified region with the
>>>> element
>>>> + * value passed in through clear_value of size clear_value_size.
>>>> + */
>>>> + void (*clear_buffer)(struct pipe_context *pipe,
>>>> + struct pipe_resource *res,
>>>> + unsigned offset,
>>>> + unsigned size,
>>>> + const void *clear_value,
>>>> + int clear_value_size);
>>>> +
>>>> /** Flush draw commands
>>>> *
>>>> * \param flags bitfield of enum pipe_flush_flags values.
>>>>
>>>
>>> Looking ahead a bit, if/when we support GL_ARB_clear_texture I wonder if
>>> we'll want to have just one pipe_context function for both purposes.
>>> We'd probably replace offset and size above with a mipmap level and
>>> x,y,z,w,h,d parameters.
>>>
>>> Do you have any thoughts on that?
>>
>> I actually already sent a set of ARB_clear_texture patches earlier
>> (e.g.https://urldefense.proofpoint.com/v1/url?u=http://patchwork.freedesktop.org/patch/21593/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=iKYKx1My9ILC23eMS7aMZJ8aOb4TXcz2TFClz1D61%2BM%3D%0A&s=85f6dd32323392e35535685b30fadf7ce24b921536974e166a4b2f849ea3950c). And I discussed
>> the single callback vs multiple callbacks thing with Marek on IRC --
>> he convinced me that having 2 separate callbacks would be better. My
>> reasoning there is that at least for nouveau, we'd still want to have
>> a separate "if PIPE_BUFFER: do this, else, do that" bit, and a shared
>> bit. It seems reasonable to have 2 diff callbacks esp since their
>> parameters are going to be reasonably different. (Instead of
>> x,y,z,w,h,d, I think a box makes sense. But same basic idea.)
>>
>> -ilia
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at 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=iKYKx1My9ILC23eMS7aMZJ8aOb4TXcz2TFClz1D61%2BM%3D%0A&s=56e0fb7f94722faaf615534370c2f16b419ca42e800790abd30ce3856852910c
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at 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=iKYKx1My9ILC23eMS7aMZJ8aOb4TXcz2TFClz1D61%2BM%3D%0A&s=56e0fb7f94722faaf615534370c2f16b419ca42e800790abd30ce3856852910c
>
More information about the mesa-dev
mailing list