PolyRectFill preformance

[Michel Dänzer]

On Sun, 2008-03-16 at 16:59 -0400, 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.

You need to check in exaPolyFillRect why it's falling back - in the case
of https://bugs.freedesktop.org/show_bug.cgi?id=12671 it's stippled
fills, though I don't really see what they're used for...


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer