ProcPutImage calls exaDoMoveOutPixmap, 4x slowdown

[Michel Dänzer]

On Thu, 2008-10-16 at 17:07 +0200, Maarten Maathuis wrote:
> On Thu, Oct 16, 2008 at 5:02 PM, Michel Dänzer
> <michel at tungstengraphics.com> wrote:
> > On Wed, 2008-10-15 at 21:59 +0200, Maarten Maathuis wrote:
> >> On Wed, Oct 15, 2008 at 9:43 PM, Eric Anholt <eric at anholt.net> 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