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) _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
