2009/12/29 Michel Dänzer <[email protected]>: > [ 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 <[email protected]>: >> > 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 <[email protected]> > > > -- > Earthling Michel Dänzer | http://www.vmware.com > Libre software enthusiast | Debian, X and DRI developer > _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
