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

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

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.http://patchwork.freedesktop.org/patch/21593/). 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
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev