[Mesa-dev] [PATCH 1/3] gallium: add expand_resource interface

[Christoph Bumiller]

On 11.07.2013 20:15, Marek Olšák wrote:
> Hi Roland,
>
> The fast color clear on Radeon doesn't touch the memory of the texture
> resource. Instead, it changes some GPU meta data that say the resource
> is cleared (the location of the meta data is stored in pipe_resource).
> This works fine as long as the gallium pipe_resource structure is used
> for accessing the resource. That's not the case with the DDX, which is
> responsible for putting the resource on the screen and it obviously
> has no idea about the contents of pipe_resource, so it doesn't know
> that the resource is in a cleared state and a special "flush"
> operation must be done to actually write the "cleared" pixels (which
> haven't been overwritten by new geometry of course).

If I was mean I would suggest you just associate the information with
the bo and have the DDX import that, too.

> The easiest way to solve this is to "flush" the cleared resource in
> SwapBuffers and where the front buffer is flushed. The Gallium driver
> can't do it automatically, because it has no notion of front and back
> buffers nor does it know which resource must be "flushed". That's why
> a new pipe_context function is being proposed, which was originally my
> idea.

You could cloak the function under a more generic name, then you're less
likely to encounter reactions like "hardware details don't belong in the
API".

First I thought of "flush_frontbuffer" from pipe_screen, but that seems
to have a different (or, no) purpose.

> This commit only fixes r600g for st/dri. Any other co-state tracker
> (like st/egl and st/xlib) will be broken if it's used with r600g. I
> think we can ignore st/xlib. Not sure how important st/egl is (not
> required for EGL under X).
>
> Marek
>
> On Wed, Jul 10, 2013 at 7:32 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>> I don't quite understand what this should do, at first sight it looks
>> like a ugly hack (which should really not be part of gallium interface)
>> to make fast color clearing work better with window framebuffers.
>> Seems to go against the idea of resources (which are immutable, well not
>> the contents but the properties).
>> (If anything I wanted an interface to change bind flags for resources
>> after initialization, because they are near impossible to guarantee with
>> OpenGL's (or d3d9 for that matter) distinct texture/fb model, but that
>> would also be quite a hack.)
>> Could you elaborate with some example what that's supposed to do in
>> practice?
>>
>> Roland
>>
>>
>> Am 10.07.2013 18:20, schrieb Grigori Goronzy:
>>> This interface is used to expand fast-cleared window system
>>> colorbuffers.
>>> ---
>>>  src/gallium/include/pipe/p_context.h                 | 8 ++++++++
>>>  src/gallium/state_trackers/dri/common/dri_drawable.c | 4 ++++
>>>  src/gallium/state_trackers/dri/drm/dri2.c            | 8 ++++++--
>>>  3 files changed, 18 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/gallium/include/pipe/p_context.h b/src/gallium/include/pipe/p_context.h
>>> index aa18cbf..38d5ee6 100644
>>> --- a/src/gallium/include/pipe/p_context.h
>>> +++ b/src/gallium/include/pipe/p_context.h
>>> @@ -354,6 +354,14 @@ struct pipe_context {
>>>                                 unsigned dstx, unsigned dsty,
>>>                                 unsigned width, unsigned height);
>>>
>>> +   /**
>>> +    * Expand a color resource in-place.
>>> +    *
>>> +    * \return TRUE if resource was expanded, FALSE otherwise
>>> +    */
>>> +   boolean (*expand_resource)(struct pipe_context *pipe,
>>> +                              struct pipe_resource *dst);
>>> +
>>>     /** Flush draw commands
>>>      *
>>>      * \param flags  bitfield of enum pipe_flush_flags values.
>>> diff --git a/src/gallium/state_trackers/dri/common/dri_drawable.c b/src/gallium/state_trackers/dri/common/dri_drawable.c
>>> index 18d8d89..b67a497 100644
>>> --- a/src/gallium/state_trackers/dri/common/dri_drawable.c
>>> +++ b/src/gallium/state_trackers/dri/common/dri_drawable.c
>>> @@ -448,6 +448,10 @@ dri_flush(__DRIcontext *cPriv,
>>>           }
>>>
>>>           /* FRONT_LEFT is resolved in drawable->flush_frontbuffer. */
>>> +      } else if (ctx->st->pipe->expand_resource) {
>>> +         /* Expand fast-cleared framebuffer */
>>> +         ctx->st->pipe->expand_resource(ctx->st->pipe,
>>> +               drawable->textures[ST_ATTACHMENT_BACK_LEFT]);
>>>        }
>>>
>>>        dri_postprocessing(ctx, drawable, ST_ATTACHMENT_BACK_LEFT);
>>> diff --git a/src/gallium/state_trackers/dri/drm/dri2.c b/src/gallium/state_trackers/dri/drm/dri2.c
>>> index 1dcc1f7..97784ec 100644
>>> --- a/src/gallium/state_trackers/dri/drm/dri2.c
>>> +++ b/src/gallium/state_trackers/dri/drm/dri2.c
>>> @@ -490,18 +490,22 @@ dri2_flush_frontbuffer(struct dri_context *ctx,
>>>  {
>>>     __DRIdrawable *dri_drawable = drawable->dPriv;
>>>     struct __DRIdri2LoaderExtensionRec *loader = drawable->sPriv->dri2.loader;
>>> +   struct pipe_context *pipe = ctx->st->pipe;
>>>
>>>     if (statt != ST_ATTACHMENT_FRONT_LEFT)
>>>        return;
>>>
>>>     if (drawable->stvis.samples > 1) {
>>> -      struct pipe_context *pipe = ctx->st->pipe;
>>> -
>>>        /* Resolve the front buffer. */
>>>        dri_pipe_blit(ctx->st->pipe,
>>>                      drawable->textures[ST_ATTACHMENT_FRONT_LEFT],
>>>                      drawable->msaa_textures[ST_ATTACHMENT_FRONT_LEFT]);
>>>        pipe->flush(pipe, NULL, 0);
>>> +   } else if (pipe->expand_resource && drawable->textures[ST_ATTACHMENT_FRONT_LEFT]) {
>>> +      /* Expand fast-cleared framebuffer */
>>> +      if (pipe->expand_resource(pipe, drawable->textures[ST_ATTACHMENT_FRONT_LEFT])) {
>>> +         pipe->flush(pipe, NULL, 0);
>>> +      }
>>>     }
>>>
>>>     if (loader->flushFrontBuffer) {
>>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev