[Mesa-dev] Mesa (master): r300g: fix texture transfers

Michel Dänzer michel at daenzer.net
Fri May 14 06:39:02 PDT 2010


On Don, 2010-05-13 at 12:11 -0700, Marek OlXXXXk wrote: 
> Module: Mesa
> Branch: master
> Commit: 60a053510155c119a6927bf7114e597066f8c50a
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=60a053510155c119a6927bf7114e597066f8c50a
> 
> Author: Marek Olšák <maraeo at gmail.com>
> Date:   Thu May 13 20:32:08 2010 +0200
> 
> r300g: fix texture transfers
> 
> The regression has first shown up after this state tracker change:
> b0427bedde80e3189524651a327235bdfddbc613.
> 
> FDO bug #28082.

[...]

> diff --git a/src/gallium/drivers/r300/r300_transfer.c b/src/gallium/drivers/r300/r300_transfer.c
> index 0dae9ef..14a9bfd 100644
> --- a/src/gallium/drivers/r300/r300_transfer.c
> +++ b/src/gallium/drivers/r300/r300_transfer.c
> @@ -127,6 +127,12 @@ r300_texture_get_transfer(struct pipe_context *ctx,
>      struct r300_transfer *trans;
>      struct pipe_resource base;
>  
> +    /* XXX Why aren't flushes taken care of by winsys automatically?
> +     * Winsys seems to sometimes return a cached buffer instead of
> +     * a mapped hardware buffer if this flush is commented out. */
> +    if (ctx->is_resource_referenced(ctx, texture, sr.face, sr.level))
> +        ctx->flush(ctx, PIPE_FLUSH_RENDER_CACHE, NULL);
> +
>      trans = CALLOC_STRUCT(r300_transfer);
>      if (trans) {
>          /* Initialize the transfer object. */

Presumably the problem is missing flushes before read transfers. Does
something like the patch below work as well? It's important for st/xorg
at least that write transfers are pipelined.

Because the state tracker can't know how the driver implements
transfers, I'm afraid the onus has to be on the driver to flush when
necessary. Maybe there could be helpers for this though.


diff --git a/src/gallium/drivers/r300/r300_transfer.c b/src/gallium/drivers/r300/r300_transfer.c
index 14a9bfd..6ff7cf2 100644
--- a/src/gallium/drivers/r300/r300_transfer.c
+++ b/src/gallium/drivers/r300/r300_transfer.c
@@ -126,12 +126,7 @@ r300_texture_get_transfer(struct pipe_context *ctx,
     struct r300_screen *r300screen = r300_screen(ctx->screen);
     struct r300_transfer *trans;
     struct pipe_resource base;
+    bool referenced = ctx->is_resource_referenced(ctx, texture, sr.face, sr.level);
 
-    /* XXX Why aren't flushes taken care of by winsys automatically?
-     * Winsys seems to sometimes return a cached buffer instead of
-     * a mapped hardware buffer if this flush is commented out. */
-    if (ctx->is_resource_referenced(ctx, texture, sr.face, sr.level))
-        ctx->flush(ctx, PIPE_FLUSH_RENDER_CACHE, NULL);
-
     trans = CALLOC_STRUCT(r300_transfer);
     if (trans) {
@@ -143,7 +146,8 @@ r300_texture_get_transfer(struct pipe_context *ctx,
 
         /* If the texture is tiled, we must create a temporary detiled texture
          * for this transfer. */
-        if (tex->microtile || tex->macrotile) {
+        if (tex->microtile || tex->macrotile ||
+            (referenced && !(usage & PIPE_TRANSFER_READ))) {
             trans->render_target_usage =
                 util_format_is_depth_or_stencil(texture->format) ?
                 PIPE_BIND_DEPTH_STENCIL :
@@ -193,11 +197,14 @@ r300_texture_get_transfer(struct pipe_context *ctx,
                 /* We cannot map a tiled texture directly because the data is
                  * in a different order, therefore we do detiling using a blit. */
                 r300_copy_from_tiled_texture(ctx, trans);
+                ctx->flush(ctx, PIPE_FLUSH_RENDER_CACHE, NULL);
             }
         } else {
             trans->transfer.stride =
                 r300_texture_get_stride(r300screen, tex, sr.level);
             trans->offset = r300_texture_get_offset(tex, sr.level, box->z, sr.face);
+            if (referenced && (usage & PIPE_TRANSFER_READ))
+                ctx->flush(ctx, PIPE_FLUSH_RENDER_CACHE, NULL);
         }
     }
     return &trans->transfer;


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer


More information about the mesa-dev mailing list