PolyRectFill preformance

Simon Thum simon.thum at gmx.de
Tue Mar 18 08:34:07 PDT 2008

Hi Ross,

is there speciality to those pages? E.g. I had similar dropouts with 
pages that had dotted lines (even in very small amounts). FF3 should fix 
that, though not checked yet.

Ross Vandegrift wrote:
> On Sun, Mar 16, 2008 at 03:40:41PM -0400, Ross Vandegrift wrote:
>> According to my profiling, these web pages are causing lots of calls to
>> *PolyRectFill.  In both EXA and XAA versions, it looks like the
>> non-accel fallbacks end up in fbBlt.  These calls are from Mozilla's
>> libgfx_gtk.
>> I'm hoping to find a simpler test case with x11perf.  I'm currently trying
>> to go through x11perf tests to see if I can find a test that'll hit
>> this, but so far no dice (the vast majority of CPU time is being spent
>> in nv_drv.so, which makes me think I haven't found the software
>> fallback yet).
>> Any tips on tracking this down?
> Following up to myself...
> My x11perf and render_bench tests finished.  None of the rect tests
> and none of the render_bench tests hit this code path.
> Briefly, here's the data I have gathered from oprofiling my box while
> testing with mozilla:
> 284083 samples from libfb.so make up 53% of measured events
> 278681 of those are from fbBlt
> Nearly all of those have this callstack:
> 	fbBlt
> 	fbOddTile
> 	fbTile
> 	fbFill
> 	fbPolyFillRect
> oprofile's callgraph doesn't include who is calling fbPolyFillRect,
> but I see 302393 cases of exaPolyFillRect -> ExaCheckPolyFillRect ->
> fbPolyFillRect, so that path seems like the most likely candidate.
> Beyond this, I can't seem to coax any data out of oprofile on what
> mozilla is doing to cause this.

More information about the xorg mailing list