Apitrace based frame retracer

[Mark Janes]

I have spent some time prototyping a frame debug/optimization tool
based on Apitrace, and I'd like to get feedback.

Apitrace's retrace functionality limits the usability of qapitrace,
because it invokes a full retrace whenever qapitrace needs more
information.  This creates big delays as the user explores the trace
file.

Finding bugs and bottlenecks in a complex GPU workload involves
exploration and experimentation.  Users need a more interactive
experience than qapitrace can provide.

I've done some hacking to set up a server process which retraces a
trace file to a specified frame, then accepts subsequent retrace
requests for renders within the frame.  Because the server process
preserves the GL state from previous frames, it can execute any frame
retrace request in the time it took the original app to render the
frame.

My proof-of-concept branch currently displays frame buffer images when
a user selects a render, with the minor modification that glClear is
called before the render, so the framebuffer only shows pixels which
were rendered by the selected call.  Also, it parses shader assemblies
from the "INTEL_DEBUG=vs,ps" setting, and displays the IR and assembly
for the render.  These features were chosen to be minimally
demonstrate the interactivity that can be accomplished with this
approach.

I've set up a wiki describing my apitrace branch, and the features I'd
like to build with a frame retracer:

https://github.com/janesma/apitrace/wiki/frameretrace-branch

The wiki has some screen shots of the features I listed above.

I'd like to get some input on the following:

 * Does anyone see technical issues with this approach?

 * Should a tool like this be built within Apitrace, or should
   it have it's own repo and link against Apitrace?  Because it
   communicates through a socket, my POC picks up protocol buffers as
   a dependency.  There is a bunch of threading/socket/rpc
   infrastructure that won't apply elsewhere in Apitrace.

 * I would like to make use of the metrics work that is being done
   this summer.  I'm eager to see the proposed metrics abstractions as
   the details are worked out.

 * Are there more use cases that I should consider, beyond what is
   described in the wiki?

thanks,

Mark