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 <srol...@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@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
