[Intel-gfx] FireFox performance regressions XAA -> EXA -> UXA

[Chris Wilson]

On Mon, 25 Jan 2010 22:18:48 -0800 (PST), "Alan W. Irwin" <irwin at beluga.phys.uvic.ca> wrote:
> On 2010-01-25 16:21-0500 Clemens Eisserer wrote:
> 
> > I did some comparisons using Carl's Firefox benchmark comparing
> > Fedora-12 (updated) with Fedora-8 (updated) using official FireFox-3.6
> > builds:
> >
> > Results are         XAA /      EXA /    UXA:
> > GMail Inbox:     39ms / 100ms / 110ms
> > tomsguide:        56ms / 158ms / 316ms
> > Heise.de            12.6ms / 46ms / 53ms
> > phoronix.com   13.4ms / 57ms / 100ms
> >
> > At least in this tests, XAA is at lot faster than both EXA/UXA. Keep
> > in mind Fedora-8 still has an old pixman version, without all the SSE2
> > optimizations added lately.
> 
> That's a pretty sobering comparison with XAA.  Factors of 3x to 7x
> performance regressions are not good.
> 
> > Ok, XAA is not fair, its comparing apples with oranges.
> 
> I assume you are referring to the fact that the modern Intel stack has lots
> of extra features.  However, the claim was made in the past that the modern
> Intel stack should eventually be comparable in speed with XAA if you stuck
> with real-world comparisons.

No, just the measurement is not directly comparable between XAA/EXA. For
XAA, firefox should be entirely doing client-side rendering with the CPU 
and just blitting the updates upon completion. Depending on how well
written the test framework is written (or whether indeed that measurement
is part of their goal, since firefox may probably only care about their
update intervals), the result may not include the time it takes for that
blit to reach the screen. Given the surprising disparity between EXA/UXA,
where I know for that version of EXA most of RENDER is driven via
fallbacks and not offloaded to the GPU, I suspect the timing script may
not be capturing the whole [system-wide] cost.

That said, we do know that the CPU (and shadow ram) is often faster than
RENDER for complex applications (simply due to the frequency that we must
write to memory using the CPU and stall/wait on the GPU) given the current
status of the drivers. And we also know that we can do much better than
the current drivers as is demonstrated by cairo-drm, which for the
majority of cases will outperform the CPU [at last!].

However, those results are quite sobering and hopefully we will be able to
use them to gain some meaningful insight into the vexed question of why
firefox does indeed feel so slow. Now all I have to track down this
mysterious script and reproduce those numbers...
-ickle

-- 
Chris Wilson, Intel Open Source Technology Centre