On Sat, 2010-10-23 at 18:48 +0100, Chris Wilson wrote: > Aye, profiling GPU code at the moment is a hard problem. If you do find > some CPU bottlenecks, they're usually the easiest to fix. What may help is > to sync every operation and see what the relative times + relative > frequencies to work out the rate limiting step and then see if you can > break it down further and repeat. (Even if we had a GPU callgrind, given > the disconnect between what is executed on the GPU and GL, it may not be > obvious how to improve the code.) uprof may help here given the > annotations Robert Brag has made for mesa profiling.
uprof looks interesting, but I couldn't see anything in git head mesa relating to it. When I profiled in the past, I noticed my use of glClear was a problem. I've reduced it by a factor of eight by more intelligent use of the stencil buffer bitplanes, and might be able to do better still with some thought about encoding and / or abuse of the depth buffer. Enabling debugging shows that I'm always falling onto the mesa meta clear path as the depth / stencil buffer is tiled on the GM45. The BLT engine can't write to that and mesa has to save and restore nearly the entire 3D state for every clear. I'm tempted to try open-coding the stencil buffer clears using GL calls as I won't need to modify so much state as mesa has to. Still, I'm not sure if there would be much difference in overhead between a big state-change and a small one. PCB design / CAD applications are very graphics intensive, so I should perhaps have looked at a heavier weight laptop to do them on, but I'd dearly love to support less performant GL capable hardware too as many of our users are on oldish hardware. Being a bit fps challenged myself helps me find more devious ways to keep frame-rate up ;) still, glxgears only manages 30fps at full screen, so I don't expect miracles! > We're always eager to improve our code to get the most of our admittedly > lack-luster GPUs. Even suggests on what tools would be useful or > improvements we could make to improve profiling/development are most > welcome. The code is already so much better. I can remember before the pre DRI2 days, pre GEM, pre KMS.. I just can't imagine a desktop without seamless compositing and GL working any more. The hard work from everyone at Intel, the mesa developers, and those working on all the other OSS drivers is really really bringing the Linux desktop up to scratch. Very very many people have a lot to be thankful to you guys for. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
