Welcome to the new apitrace mailing list
jose.r.fonseca at gmail.com
Wed Aug 24 15:03:10 PDT 2011
On Wed, Aug 24, 2011 at 8:55 PM, Carl Worth <cworth at cworth.org> wrote:
> On Tue, 23 Aug 2011 06:28:16 -0700 (PDT), Jose Fonseca <jfonseca at vmware.com> wrote:
>> I look forward to hearing what ideas you have.
>> FYI, the enhancements/issues that I'm aware are in mostly tracked in
>> https://github.com/apitrace/apitrace/issues or
> Thanks for sharing those.
> Most of my current ideas/plans are hinted at already in a couple of
> existing items:
> * Ability to extract just a single frame from a trace, and all
> previous calls that contributed to it:
The ability to extract a frame is indeed the holy grail here. It's not
an easy feat.
I thought of two basic approaches so far, both relying on the ability
of iterating over all GL state:
A) for each call before the frame of interest, compute a hash function
for whole the GL state, and drop the function when the hash value does
not change, or drop a range of functions when the hash value matches
an earlier function.
B) retrace all calls up-to the frame of interest, iterate all GL
state, emitting fake functions that recreate this state
Approach A has the advantage that it does not need to be prefect, it
could be interfactive: -- a tool would produce a suggestion, then a
human could toggle the functions to be included/excluded, before the
trace was actually pruned by another tool.
Approach B is convenient for on-demand tracing -- we could use the
same code for defering the start of the trace until a key is pressed
--, and also incremental/successive textures/buffer uploads would be
reduced to their value.
As I said, both methods imply the ability of iterating over all GL
state. There is already the ability to iterate over a bulk of the
current state (current context, current textures, current shaders) in
glstate* source files, used to dump the GL state to the qapitrace GUI.
We'd need to extend this to _all_ state really
> * Timeline view
The only open question in my mind here, is how much should be done a
trace time, vs glretrace time. Trace times describe the original
application. But the nice thing about measuring at glretrace time is
that it can be automated, used for regressions, side-by-side
As you read elswhere, work on this started. A major obstacle for
timings was the overhead of (d)compressing, but Zack has done an
excellent job in speeding that. Liu already has some prototype of the
> It's good to see we're thinking along some of the same lines there. So
> consider my hand raised to start working on those things.
> PS. Here are some notes I wrote up with a little more detail on the
> tasks I would like to tackle (or see someone tackle) for apitrace. The
> letters in brackets refer to a task depending on one or more previous
> L. Add mode to ApiTrace to dump a sequence of rendered images
> M. Add mode to ApiTrace to do exact image comparisons of each frame
> with existing reference images [L].
> N. Investigate tools for doing "visual similarity" rather than exact
> comparisons for image testing.
> O. Implement visual similarity in ApiTrace-based conformance testing
I believe L/N/O already exists: glretrace has the -s and -c options to
compare, and I've been using glretrace based testing for several
There is no exact comparison, but that would be trivial.
There is also a bunch of scripts in scripts subdir for things such as
bisection of bugs with glretrace, or side-by-side comparison of trace
rendering vs a reference GL implementation (ie., a software renderer,
or a old version of the driver)
More information about the apitrace