[Mesa-dev] [PATCH 1/3] gallium: add expand_resource interface
Marek Olšák
maraeo at gmail.com
Thu Jul 11 11:15:14 PDT 2013
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).
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.
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
More information about the mesa-dev
mailing list