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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel