xorg-server CVS and EXA [SOLVED]

[Michel Dänzer]

On Mon, 2006-04-24 at 14:14 -0400, Adam Jackson wrote:
> On Monday 24 April 2006 03:03, Michel Dänzer wrote:
> > 256KB seems to be the limit for a single PutImage request, so if the
> > image data is bigger than that, it has to be chopped up into several
> > requests.
> 
> Nice find.  

Thanks; as in 'please commit to HEAD and 1.1 branch'? :)

> Yes, for wire PutImages, we max out at just under 256k because PutImage 
> isn't automatically bigrequested.  I think Roland opened a bug about that 
> ages ago, and it'd probably be a win to do bigreq'd PutImage up to some 
> threshold (at the point where either interactivity suffers or you lose 
> performance due to cache thrash).

Actually, smaller chunks might even improve throughput under some
circumstances thanks to parallelization. Measuring this should be
interesting.


> > PS: Random unrelated EXA performance observation: At least with the
> > "smart" migration heuristics, DownloadFromScreen seems to be a net win
> > even when it's not accelerated (as is the case with the radeon driver).
> > Disabling it altogether instead about doubles x11perf -getimage scores
> > here but cripples x11perf -putimage scores to 25-30% and also seems to
> > make my normal GNOME session more sluggish.
> 
> I'm not sure why this would be true; 

Neither am I, and of course observations like 'seems to make more
sluggish' come with pretty big grains of salt. Maybe it's rather due to
the migration scheme itself.

> but if it were, it would make sense to supply a default DFS memcpy stub 
> in exa itself rather than one in every driver.

Yeah, or change the migration logic accordingly.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer