Welcome to the new apitrace mailing list

José Fonseca 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
>> https://github.com/apitrace/apitrace/blob/master/TODO.markdown
>
> 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
comparisons etc.

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
measurements.


> 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.
>
> -Carl

> 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
> tasks.
>
[...]

> 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
>   [M,N].

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
months now.

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)

Jose


More information about the apitrace mailing list