xorg-server CVS and EXA

[Michel Dänzer]

On Sat, 2006-04-22 at 11:06 +0200, Michel Dänzer wrote:
> On Fri, 2006-04-21 at 18:19 +0000, morgoth6 at box43.pl wrote:
> > 
> > As I noticed the new Migration Heuristic schema looking at Xorg cvs logs 
> > and I decide to give a try to EXA one more time. But it seems I am still 
> > out of luck :) Enabling EXA on my machine (Pegaos II && Radeon 9000) gives 
> > me a realy funny effect - http://www.tbs-software.com/morgoth/files/private/migration-smart.png
> 
> I'm seeing the same; it looks like every other stripe of some pixmaps
> contains garbage from other pixmaps. As I suspect Eric wouldn't have
> committed this if he saw the same :), and I'm also running on an M9 and
> PPC, I suspect this may be specific to some aspect of our setups.

This is a weird one! I spent the better part of today trying to track it
down, here's what I've found so far.

It's related to exaPutImage's invocation of UploadToScreen. The other
users of UploadToScreen seem fine.

Interestingly, the corruption occurs even if RADEONUploadToScreen's
HostDataBlit calls are disabled, i.e. when it uses only direct memcpy to
the framebuffer. However, if it returns FALSE (or if the driver doesn't
set the UploadToScreen hook), everything's fine.

So I tried to find a difference between exaPutImage's UploadToScreen
call and its fallback code, but couldn't find any.

Now for the really weird part: I noticed that the corruption seems to
occur as soon as the image source data (h * src_stride) exceeds about
256KB. I'm currently running with exaPutImage modified to only call
UploadToScreen if h * src_stride < 250 *1024, and things are mostly
happy (The notification-daemon popups are still corrupted, but I don't
know if that's the same problem).

So what's special about 256KB? Well for one thing, that's the size of my
L2 cache...

Considering all of the above (and the regularity between corruption and
correct appearance in the PutImage rendering), I'm currently suspecting
a caching issue somewhere along the way of the image data transport.
Unless someone has a better idea (which is quite possible, if you do,
please speak up! :), I'm gonna toy with that idea for a bit, e.g. try
replacing the memcpy calls in RADEONUploadToScreen with assignment
loops.

This hypothesis leaves me wondering though why the "greedy" migration
heuristics don't show this problem. Maybe they never actually hit the
UploadToScreen calls in exaPutImage.


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