2010/2/15 Michel Dänzer <[email protected]>: > On Thu, 2010-02-11 at 20:06 +0100, Maarten Maathuis wrote: >> 2010/2/11 Michel Dänzer <[email protected]>: >> > >> > Thanks for tackling this, Maarten! >> > >> > On Thu, 2010-02-11 at 19:05 +0100, Maarten Maathuis wrote: >> >> - A mapped pixmap can't be used for acceleration, any decent memory >> >> manager >> >> will refuse this. >> >> - Source pixmaps may need updating, so move in the pixmap >> >> unconditionally, it >> >> should be a no-op in most cases anyway. >> > >> > 'May need'? Have you actually observed this in practice? Only the mixed >> > pixmap pointed to by pExaScr->deferred_mixed_pixmap should ever have >> > valid bits in the system memory copy with no corresponding valid bits in >> > the GPU copy. In which case the new code could still be conditionalized >> > on >> >> Yes i have observed this in practice, the reason is "fairly" obvious. >> >> Do software rendering on full pixmap, do hardware rendering as src >> with preg (driver pixmap created), do software rendering (sw pixmap is >> killed, but not everything is in hardware pixmap yet). > > [...] > >> One possibility would be to put "exaDoMigration" with src with preg on >> the deferred pixmap list, i haven't tested this, but i could try this >> evening or tomorrow. > > Thanks for the clarification and for the extra effort to show another > possible approach. I agree the first approach is cleaner. > > >> > It should be possible to restructure the code such that the late_failure >> > label and goto aren't necessary. >> >> You cannot assume the prepare access to succeed the 2nd time, although >> it will in 99.99% of the time. > > No such assumption is necessary: > > * Call ExaDoPrepareAccess(). > * On success, do the new thing, call ExaDoPrepareAccess() again. > * Take the current failure path if either ExaDoPrepareAccess() > call failed.
But that will mean you need a goto, a for loop (in the beginning), code duplication or something else. I just took the goto as least invasive. > > >> > Is there a bug report that can be referenced in the commit message? >> >> Not to my knowledge. > > http://bugs.freedesktop.org/show_bug.cgi?id=26076 ? > I forgot about that one, and somehow i didn't show up in my bug search. > > -- > Earthling Michel Dänzer | http://www.vmware.com > Libre software enthusiast | Debian, X and DRI developer > > > Will send an updated patch this evening. _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
