2009/12/5 Michel Dänzer <[email protected]>: > On Sat, 2009-12-05 at 17:59 +0100, Maarten Maathuis wrote: >> 2009/12/5 Michel Dänzer <[email protected]>: >> > On Fri, 2009-12-04 at 20:28 +0100, Maarten Maathuis wrote: >> >> 2009/12/4 Michel Dänzer <[email protected]>: >> >> > >> >> > + if (pExaPixmap->pDamage && pExaPixmap->sys_ptr) { >> >> > + free(pExaPixmap->sys_ptr); >> >> > + pExaPixmap->sys_ptr = NULL; >> >> > + DamageUnregister(&pPixmap->drawable, pExaPixmap->pDamage); >> >> > + DamageDestroy(pExaPixmap->pDamage); >> >> > + pExaPixmap->pDamage = NULL; >> >> > + REGION_EMPTY(pScreen, &pExaPixmap->validSys); >> >> > + >> >> > + swap(pExaScr, pScreen, ModifyPixmapHeader); >> >> > + pScreen->ModifyPixmapHeader(pPixmap, width, height, depth, >> >> > + bitsPerPixel, devKind, >> >> > pPixData); >> >> > + swap(pExaScr, pScreen, ModifyPixmapHeader); >> >> > + >> >> >> >> How is this helping, considering it's done twice (the original MPH >> >> still exists)? >> > >> > That won't be called if the driver MPH hook returns TRUE. >> >> Not every driver has an MPH hook and they certainly don't return TRUE >> all the time. Why not remove the MPH here and just stick to deleting >> the sysram copy? > > I'll try that. > >> (don't forget deferred pixmaps) > > What do you suggest should be done about them here? Note that I was > going to propose removing deferred pixmaps again, they seem to cause > problems with optimized migration and the latter seems to help more.
You need to copy back deferred content to the gpu pixmap. Isn't optimized migration on by default? (i didn't notice problems in my wfb-less testing) > > > -- > 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
