radeon EXA performance questions

[Simon Thum]

Michel Dänzer wrote:
> On Fri, 2008-08-01 at 12:40 +0200, Simon Thum wrote:
>> Michel Dänzer wrote:
>>>> complex app takes 1/3 sec or even more). Obviously some ops are still 
>>>> suboptimal. Is there interest in oprofile data?
>>> Sure, though I prefer sysprof (or at least output from opreport -c as
>>> well as opreport -l).
>> Said, done. I didn't experience the dropout, but this profile should 
>> capture what I mean. I switched eclipse, firefox and thunderbird, 
>> scrolling a lot in the latter over this lovely mailing list. This is a 
>> particular slow thing in EXA, roughly comparable to unpatched XAA with 
>> offscreen pixmaps.
> 
> Note that every profile should be limited to a single isolated action as
> much as possible in order to maximize its usefulness.
True. But I guess in this case there is a common problem.

> This profile shows 40% of the cycles spent copying data from video RAM
> to system RAM for GetImage (Not sure what that's used for in the actions
> described above...).
Same here, it could be 80% FB moves and 20% uploads. Owen's hint to 
locking seems reasonable though.

> It also shows that you don't have the DRI enabled. The radeon driver is
> known to perform much better with it enabled. Have you tried that (and
> maybe also enabling Option "AccelDFS")?
Well, it's my dev instance. Since I'm just on my pointer accel, I 
disabled DRI to save some work. AccelDFS, don't know what it is, and it 
seems to only work when DRI is enabled. Smart migration gave a 
(subjectively) minor boost.

Seems I need to make my homework first :(

>> Maybe it makes sense to put a similar constraint into EXA pixmap 
>> migration that my patch (previous mail) had caused in XAA? Is that 
>> possible somehow?
> 
> It would be possible, but the effect may not be comparable, as EXA and
> XAA use offscreen pixmaps completely differently.
Yeah, I hacked a thing up but got nothing but display corruption. 
Nice-looking corruption though.

Thanks for the help,

Simon