[Intel-gfx] Corruption in glxgears with Compiz

[Peter Clifton]

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)