jordan at cosmicpenguin.net
Mon Dec 22 17:51:08 EST 2008
Greg Smith wrote:
> Hi Jordan,
> Looks like we made a little more progress on graphics benchmarking. See
> Neil's results below.
> I updated the feature page with the test results so far:
> What's next?
> Do we know enough now to target a particular section of the code for
My previous email was pretty long, so I thought I would answer this last
question separately. I can help guide you with the operations that are
slower with acceleration. There may be other optimizations to be had
within cairo or elsewhere in the X world, but I'll have to leave those
to people who understand that code better.
The majority of the operations will probably be composite operations.
You will want to instrument the three composite hooks in the X driver
and their sub-functions: lx_check_composite, lx_prepare_composite, and
lx_do_composite (in lx_exa.c).
lx_check_composite is the function where EXA checks to see if we are
willing to do the operation at all - most of the acceleration rejects
should happen here. lx_prepare_composite is where we store the
information we need for the ensuing composite operation(s) - we can also
bail out here, but there is an incremental cost in leading EXA further
down the primrose path before rejecting it. lx_do_composite() obviously
is where the operation happens. You will want to concentrate on these
functions - instrument the code to figure out why we accept or reject an
operation and why we take so long in rejecting certain operations.
Profiling these functions may also help you figure out where we are
spending our time.
So, in short - become one with the ErrorF() and good luck... :)
More information about the Devel