xorg-server CVS and EXA [SOLVED]

Michel Dänzer michel at daenzer.net
Mon Apr 24 00:03:08 PDT 2006

On Sat, 2006-04-22 at 19:41 +0200, Michel Dänzer wrote:
> 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...

Fortunately, things turned out not to be quite as mysterious. :)

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. I noticed that in this case, only every second invocation of
exaPutImage takes the UploadToScreen path, and those are the corrupted
pieces. The other invocations fall back to software because the drawable
pixmap isn't offscreen. I was about to punt this to Eric as a weird
migration ping pong, but then I noticed that exaPutImage doesn't mark
the drawable as dirty in the UploadToScreen path. The attached patch
fixes it for me. Eric, does this make sense?

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.

Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: exa-putimage-markdirty.diff
Type: text/x-patch
Size: 616 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060424/5e6dbb48/attachment.bin>

More information about the xorg mailing list