On Thu, 2008-10-16 at 17:07 +0200, Maarten Maathuis wrote: > On Thu, Oct 16, 2008 at 5:02 PM, Michel Dänzer > <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-10-15 at 21:59 +0200, Maarten Maathuis wrote: > >> On Wed, Oct 15, 2008 at 9:43 PM, Eric Anholt <[EMAIL PROTECTED]> wrote: > >> > > >> > Migrating out for a write-only operation is just broken, and is the > >> > thing that should be fixed there. > > > > There is no actual migration here, just superfluous syncing fixed by my > > patch. > > What makes you so sure, the standard thing to do on a fallback is migrate out.
You mean apart from the fact that my patch helped Clemens? ;) Seriously, though: ExaCheckPutImage() passes the pending damage region as the destination region that does not need to be migrated because it will be overwritten by the operation. So exaCopyDirty() ends up with an empty CopyReg. > >> I'd like to add that if anything changes in this beheaviour, then this > >> shouldn't be done quietly. Because some may depend on this (offscreen > >> memory tiled and needing migration to have something linear available > >> for example). > > > > Sounds like something that could be handled in UploadToScreen. > > I'm assuming a case where UTS and DFS do the conversion, but direct > cpu access is a bad idea. Fortunately exa *never* does this currently, > prepare access always triggers a migration out. And even if it didn't (e.g. with non-default values for Option "MigrationHeuristic"), the driver can force this by returning FALSE from its PrepareAccess hook. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
