[PATCH 1/4] EXA: Don't use UTS/DFS directly for Put/GetImage when there's a system copy.

[Maarten Maathuis]

2009/12/29 Michel Dänzer <michel at daenzer.net>:
> [ Adding Thomas to CC in case he wants to comment as well ]
>
> On Tue, 2009-12-29 at 12:41 +0100, Maarten Maathuis wrote:
>> 2009/12/28 Michel Dänzer <michel at daenzer.net>:
>> > On Mon, 2009-12-28 at 13:37 +0100, Maarten Maathuis wrote:
>> >> What kind of situation are you trying to improve here?
>> >
>> > Same as for the UploadToScreen case in exaHWCopyNtoN(); avoiding GPU
>> > copy readbacks when the GPU copy isn't directly accessible.
>>
>> I wonder how many apps do CreatePixmap, PutImage, CopyArea,
>> DestroyPixmap, because in that scenario i don't like the change (the
>> UTS path CopyNtoN was pretty rare to be used).
>
> Would this change affect that case at all? pExaPixmap->pDamage should be
> NULL in exaDoPutImage.

You are right, for purely hardware operations pDamage wouldn't exist.
I am ok with the situation then.

>
> Note that even in a similar scenario where this change does make a
> difference, it only adds one memcpy from and to cacheable memory.

In the current situation wfb works for us(nouveau, nv50) just as good
as without, with the added advantage of less memory consumption. But
it does mean i have to keep an open eye for relevant changes. Right
now i'm not worried, because the only code path that changes is the
one in which a PutImage or GetImage occurs after an operation that
starts with a fallback. Those will benefit anyway (remember that
pDamage is gone as soon as prepare access succeeds on a driver
pixmap).

So, Acked-By: Maarten Maathuis <madman2003 at gmail.com>

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