[Mesa-dev] Mesa (master): r300g: fix texture transfers
Marek Olšák
maraeo at gmail.com
Fri May 14 07:40:52 PDT 2010
Unfortunately, your patch returns the previous behavior where framebuffer
readbacks don't work sometimes. I think the real issue is somewhere in the
buffer management in winsys.
-Marek
2010/5/14 Michel Dänzer <michel at daenzer.net>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100514/d9350c59/attachment.html>
More information about the mesa-dev
mailing list