performance work

[Jordan Crouse]

Greg Smith wrote:
> Forwarding this to devel.
> 
> Any comments or suggestions on how we can start to optimize graphics 
> performance is appreciated.

That is a rather open ended question.  I'll try to point you at some 
interesting places to start with the understanding that not one thing
is going to solve your all problems - the total processing time is 
almost definitely a cumulative effect of all of the different stages of 
the rendering pipeline.

I would start by establishing a 1:1 baseline - it is great to compare 
against a 2Ghz Intel box, but that the differences between the two 
platforms are just too extreme.  No matter how good the graphics gets, 
we are still constrained by the Geode clock speed, FPU performance, and 
GPU feature set (what it can, and most importantly _cannot_ do).

The first thing you need to do is determine which operations you really 
care about. I would first target the operations that deal with text and 
rounded corners, since those will be the most complex. Straight blits 
and rectangle fills are important, but less interesting, since they 
involve the least work in the path between you and the GPU.

I recommend running the Cairo benchmarks on the XO again with 
acceleration turned off in the X driver. This will give you a good 
indication of which operations are being accelerated and which are not. 
  If you have another Geode platform handy (which you should if you are 
at 1CC), then you might also want to run the same benchmarks again 
against the vesa driver (which will be completely unaccelerated).  The 
difference in the three sets of data will give you a good idea of which 
operations are unaccelerated, and which operations are being further 
delayed by the Geode X driver.

The low hanging fruit here are the operations that are not being 
accelerated; you will need to determine why.  Sometimes its because the 
GPU cannot handle the operation (for example, operations on a8 
destinations), or it might because the operation was never implemented 
in the code, or it could be that the code is just downright buggy.
This is where it is imortant to know which operations you care most 
about.  You could probably find a good number of bugs in the two pass 
operations (PictOpXor and PictOpAtop) but both are rarely used and not a 
good use of your time.  I have no problems at all with biasing the 
driver toward very common operations.  If there is something that can be 
done to the driver to improve text rendering at the cost of say, 
rotation, then I'm all for it.

Outside of the driver, you are pretty much limited to evaluating 
alogrithms, either in the software render code (pixman) or in the cairo 
code.  For those situations, I have less knowledge, but I do advise you 
to remember the two hardware constraints which I mentioned above - CPU 
clock speed and FPU performance.  Remember that alot of this code was 
written recently when nobody in their right mind has < 1Ghz on their 
desktop - no matter how hard they try, this will end up biasing the code 
slightly.  FPU performance is more serious. The Geode does not do well 
with heavy FPU use - to mitigate the damage, try to use single precision 
only, and try not to use a lot of FPU operations in a row because the 
Geode pipeline stalls horribly if two FPU operations are scheduled one 
after another.

Finally, I will remind you that you that no amount of hacking is going 
to magically make the Geode + Geode GPU all of a sudden look like a 
modern desktop Radeon.  There are many modern GPU concepts that desktop 
toolkits are becoming increasingly dependent on that the Geode just 
cannot grok.  Fading icons and anti-aliasing and animations may look 
really neat on your 2Ghz Intel, but they are a major strain on CPU 
resources on the Geode.  I'm not saying that there isn't room for 
improvement, but I am saying that at some point you will have to make 
compromises between what the UI does, and what the hardware can do. 
Until you are willing to bite that bullet, any optimizations you under 
the hood will be a treatment but never a cure.

Jordan