Another GPU profile (with better CPU code)

[Peter Clifton <pcjc2@cam.ac.uk>]

This one is clearer, as I used a huge displaylist to keep the GPU busy.
It is the same frame as in the previous graphs, just in a displaylist.

There are still some obvious stalls which aren't easy to explain. I've
highlighted them in red, but note that there are two different "classes"
of stall, some leave the geometry shader idle, some do not.

Just thinking out loud here.. is there a render cache flush going on
during these intervals, or is there some arbitration issue between the
render cache and other memory streams?

Clearly whatever is going on is starving some units (making them idle)
and not others. CS, for example remains at 100% throughout (although not
shown on the graphs).

Those which go idle:

VS0, (GS sometimes), CLIP, SETUP, WM, PS, Dispatch, URB

Those which sit at 100% non-idle:

RC, WIZ, SF, (GS sometimes), VF, CS

I'm guessing what this means is that VS0 is being starved of access to
the vertex buffers it is rendering from, and downstream units then go
idle. Or there is some other state flush / state change going on which
has paused rendering?


The graphs are pretty though right? ;)

I think I need to get some more info from the kernel to sync up the
graphs with actual rendering commands / batchbuffers. Perhaps there is
somewhere in MMIO space I can write to to pass some information to the
polling userspace program which looks at the instdone regs, but perhaps
there is a "clever" way.

Best wishes,

-- 
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)