On 04/02/2014 04:40 PM, Rob Clark wrote:
> On Wed, Apr 2, 2014 at 3:47 AM, Thomas Hellstrom <thellst...@vmware.com>
> wrote:
>> On 04/01/2014 05:04 PM, Rob Clark wrote:
>>> From: Rob Clark <robcl...@freedesktop.org>
>>>
>>> Otherwise it will trick the gallium driver into thinking that the render
>>> target has actually changed (due to different pipe_surface pointing to
>>> same underlying pipe_resource). This is really badness for tiling GPUs
>>> like adreno.
>> Rob, if we want to cache gallium surfaces like this, we need to
>> condition it on the same context being used.
>> We can't reuse a surface created with one context for rendering with
>> another context. (I know the mesa state tracker needs to
>> fix this up as well).
> oh.. ugg.. do we have any cases where multiple XA contexts are used?
> Or could we take the easy way out and somehow forbid that?
Hmm. It was designed around the idea of multiple XA contexts so if at
all possible I think we should
continue to allow that..
>
>> While this can be done easily within XA for non-shared xa_surfaces, I
>> wonder what happens in the case of
>> shared xa_surfaces? More specifically, is rendering allowed to be cached
>> in the gallium surface until explicitly flushed to the texture? (I'm
>> unsure about gallium surface semantics here).
> I'm not quite sure either. I need to flush rendering whenever the
> render target actually changes (I'm just trying to prevent flushing
> when the render target doesn't change, but only the pipe_surface ptr
> does). If you are using that surface as a texture, then presumably
> you needed to change the render target.
>
> I'm less sure about other drivers.
>
> I suppose a different approach would simply be to cache the most
> recent pipe_surface. So whenever the render target does actually
> change, we create a new pipe_surface. But we avoid creating a new
> surface for the same render target when it doesn't change.
>
> BR,
> -R
>
>
Something along the line of the attached patch? That would keep a
reference on the destination surface until context destruction, but I
guess the driver would do that anyway, since it's a render target...
/Thomas
>From 26cb8fc9b19c023b5666d1c105888263b0b14d23 Mon Sep 17 00:00:00 2001
From: Thomas Hellstrom <thellst...@vmware.com>
Date: Wed, 2 Apr 2014 19:50:09 +0200
Subject: [PATCH 4/4] st/xa: Cache render target surface
Otherwise it will trick the gallium driver into thinking that the render
target has actually changed (due to different pipe_surface pointing to
same underlying pipe_resource). This is really badness for tiling GPUs
like adreno.
Signed-off-by: Thomas Hellstrom <thellst...@vmware.com>
---
src/gallium/state_trackers/xa/xa_context.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_context.c b/src/gallium/state_trackers/xa/xa_context.c
index 867999a..37de45b 100644
--- a/src/gallium/state_trackers/xa/xa_context.c
+++ b/src/gallium/state_trackers/xa/xa_context.c
@@ -78,6 +78,8 @@ xa_context_destroy(struct xa_context *r)
}
xa_ctx_sampler_views_destroy(r);
+ if (r->srf)
+ pipe_surface_reference(&r->srf, NULL);
if (r->cso) {
cso_release_all(r->cso);
@@ -185,8 +187,15 @@ xa_ctx_srf_create(struct xa_context *ctx, struct xa_surface *dst)
struct pipe_screen *screen = ctx->pipe->screen;
struct pipe_surface srf_templ;
- if (ctx->srf)
- return -XA_ERR_INVAL;
+ /*
+ * Cache surfaces unless we change render target
+ */
+ if (ctx->srf) {
+ if (ctx->srf->texture == dst->tex)
+ return XA_ERR_NONE;
+
+ pipe_surface_reference(&ctx->srf, NULL);
+ }
if (!screen->is_format_supported(screen, dst->tex->format,
PIPE_TEXTURE_2D, 0,
@@ -204,7 +213,10 @@ xa_ctx_srf_create(struct xa_context *ctx, struct xa_surface *dst)
void
xa_ctx_srf_destroy(struct xa_context *ctx)
{
- pipe_surface_reference(&ctx->srf, NULL);
+ /*
+ * Cache surfaces unless we change render target.
+ * Final destruction on context destroy.
+ */
}
XA_EXPORT int
--
1.7.10.4
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
