I understand, though the current hackish approach in the radeon (and
also nouveau) drivers has been working really well for the last 3
years and it doesn't look like anybody would like to change that. Just
saying. Not that it's important.
Marek
On Fri, Jun 7, 2013 at 4:57 PM, Roland Scheidegger <srol...@vmware.com> wrote:
> 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.
>
> Roland
>
>>
>> Marek
>>
>>> usage |= PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE;
>>> } else {
>>> --
>>> 1.7.9.5
>>> _______________________________________________
>>> 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
