Hi Jordan et al, Thanks a lot for the advice. I'm forking this thread and will reply on the other one too.
One question here on your suggested methodology. Are you suggesting that we try those X composite hooks and then re-run the benchmark to see if it improves? All, Is anyone interested in getting in to this X windows code? We have some momentum now including a test bed and baseline results so it may be the right time to work on everybody's favorite bugaboo: performance. Thanks, Greg S Jordan Crouse wrote: > 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: >> http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness >> >> What's next? >> >> Do we know enough now to target a particular section of the code for >> optimization? >> > 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... :) > > Jordan > _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel