[Mesa-dev] [PATCH 2/2] util: fix util_clear_render_target and util_clear_depth_stencil layer handling

Jose Fonseca jfonseca at vmware.com
Fri Jun 7 08:07:30 PDT 2013


----- Original Message -----
> Am 07.06.2013 12:14, schrieb Marek Olšák:
> >> diff --git a/src/gallium/auxiliary/util/u_transfer.c
> >> b/src/gallium/auxiliary/util/u_transfer.c
> >> index 56e059b..7804f2a 100644
> >> --- a/src/gallium/auxiliary/util/u_transfer.c
> >> +++ b/src/gallium/auxiliary/util/u_transfer.c
> >> @@ -25,6 +25,7 @@ void u_default_transfer_inline_write( struct
> >> pipe_context *pipe,
> >>     usage |= PIPE_TRANSFER_WRITE;
> >>
> >>     /* transfer_inline_write implicitly discards the rewritten buffer
> >>     range */
> >> +   /* XXX this looks very broken for non-buffer resources having more
> >> than one dim. */
> >>     if (box->x == 0 && box->width == resource->width0) {
> > 
> > Indeed, however radeon drivers ignore the discard flags for textures
> > and if the transfer is write-only, they behave as if DISCARD_RANGE was
> > set no matter what the flags are. It's a respond to state trackers not
> > having used the discard flags when they should (that is: always). I
> > propose to standardize this behavior, i.e. if PIPE_TRANSFER_READ is
> > not set for texture transfers, PIPE_TRANSFER_DISCARD_RANGE is implied.
> 
> I think that's a bit awkward to make it the state tracker's
> responsibility to set PIPE_TRANSFER_READ if it doesn't want to write the
> whole range, setting TRANSFER_DISCARD_RANGE if it does want to write
> everything sounds more natural and safe to me.
> If state trackers don't do this they should just be fixed.

I agree with Roland. There's nothing radically different between a buffer and a texture to grant special treatment.  Let's be explicit about these flags, instead of relying the implied flags and/or guessing intentions.  


Jose


More information about the mesa-dev mailing list