This Android.mk is part of "Bug 831147 - Integrate apitrace into build"
https://bugzilla.mozilla.org/831147 With this addition, when apitrace
sources are cloned into B2GROOT/external/apitrace, then the FirefoxOS
build system picks up automatically apitrace, compiles and installs it
to the right place.
Signed-off-by: José Fonseca <jose.r.fonseca@gmail.com>
Carl Worth [Thu, 21 Mar 2013 23:01:25 +0000 (16:01 -0700)]
trim: Enable dependency analysis (--auto) by default.
The --exact mode of trimming can be useful, but only if the user has
somehow performed all the dependency analysis needed manually, (such
as by extracting a list of calls from a previous run by
--print-callset). Since --exact inherently requires more care to be
used, it makes sense to also require an extra command-line option, and
to thus prefer the easier-to-use --auto mode by default.
Carl Worth [Thu, 21 Mar 2013 22:49:58 +0000 (15:49 -0700)]
trim: Add --no-deps, --no-prune, and --exact options.
These allow for explicitly specifying the behavior desired. This
change anticipates some future change of the default trimming from
--exact to --auto. (That is, with these options in place, scripts can
be written today with either --exact or --auto and be immune to any
future change of the default.)
Carl Worth [Fri, 12 Apr 2013 21:23:00 +0000 (14:23 -0700)]
Fix sorting of callFlagTable
Commit 89681160639 inserted three entries in an unsorted position in
the list, tripping up an internal check and causing many apitrace
operations to abort. Fix this by restoring correct sorting.
Carl Worth [Fri, 15 Feb 2013 02:09:14 +0000 (18:09 -0800)]
trim: Greatly expand the list of calls considered to have no side effects
The list of calls added here with the NO_SIDE_EFFECTS flag was
obtained from the existing specs/glapi.py file, (most[*] calls with
"sideeffects=False").
It's a bit unfortunate that we have this duplication of information in
the source tree, (two different lists of calls with no side
effects). But that duplication was already present before this
commit. This commit merely brings this list into sync with the other.
[*] The following calls are not added here in spite of having
sideeffects=False in glapi.py:
José reports that the above calls can have side effects when PBOs are
on, (and he plans to update glapi.py).
Then, while the following calls may not affect traditional "GL state"
they do have side effects that can be observed by the user. And these
are debugging side effects that can be very important when
replaying/analyzing a trace. For example, debug message or string
markers are used to decorate different portions of the graphics
command stream with user-supplied data that exists nowhere else. So
these calls are not considered as having no side effects:
Carl Worth [Sat, 16 Feb 2013 01:15:53 +0000 (17:15 -0800)]
trim: Don't consider a SwapBuffers call has having no side effects
I can't justify why I ever added this code. I can only guess that I was
trying to get qapitrace to not show frame markers for frames that had
largely been trimmed.
Anyway, the code is wrong. SwapBuffers call obviously have significant
side effects. And the effect I was trying to achieve is already well
satisified by the change in 2f0d1a3244c8953a4468759ac466b80c4965d38f
that will trim a SwapBuffers call when --trim-spec=drawing is in
force.
Carl Worth [Sat, 16 Feb 2013 00:31:11 +0000 (16:31 -0800)]
trim --prune: Look at FLAG_NO_SIDE_EFFECTS rather than FLAG_VERBOSE
The --prune option is documented precisely to prune calls with no side
effects, so that's the flag it should examine.
Previously, the trim --prune code was keying off of the VERBOSE
flag. This hasn't made a substantial difference in the past, (the
NO_SIDE_EFFECTS calls have historically all been VERBOSE as well). But
NO_SIDE_EFFECTS has the advantage that it can objectively determined,
so the set of calls that should have this flag should be
unambiguous. (Meanwhile, whether any particular call should be
classified as VERBOSE is inherently subjective.)
Carl Worth [Thu, 21 Mar 2013 22:52:19 +0000 (15:52 -0700)]
glretrace: Flush outstanding requests when waiting for user input.
This helps make "apitrace replay -sb" work in cases where the driver
really only exposes double-buffered rendering, (so a flush is required
to make anything appear if the trace doesn't include a final
SwapBuffers).
Rob Clark [Mon, 11 Mar 2013 17:21:25 +0000 (13:21 -0400)]
gui: Link against pthread.
/usr/bin/ld: CMakeFiles/qapitrace.dir/apitracecall.cpp.o: undefined
reference to symbol '__pthread_key_create@@GLIBC_2.2.5'
/usr/bin/ld: note: '__pthread_key_create@@GLIBC_2.2.5' is defined in DSO
/lib64/libpthread.so.0 so try adding it to the linker command line
/lib64/libpthread.so.0: could not read symbols: Invalid operation
Carl Worth [Mon, 11 Feb 2013 21:49:02 +0000 (13:49 -0800)]
cli: Rename "apitrace retrace" to "apitrace replay".
After some debate on the mailing list, the consensus favors the name
"replay" for this operation. Update the documentation in
README.markdown to match.
Carl Worth [Tue, 28 Aug 2012 18:45:52 +0000 (11:45 -0700)]
replay: Support applications mixing glCreateProgramObjectARB and glUseProgram
As is known to happen with OpenGL, there are many more than one ways
to do the same thing. In this case, one can create a program
(glCreateProgram) or a program object (glCreateProgramObjectARB) along
with many similar pairs of functions.
In fact, a single application might even mix these two approaches,
(for example, calling glCreateProgramObjectARB and then calling
glUseProgram rather than glUseProgramObjectARB).
Historically, glretrace could fail with such mixed usage. The calls
into the ObjectARB function would go through _handleARB_map while the
other calls would go through _program_map, so after mixed calls the
desired object would not be found in the referenced map.
Making mixed usage work requires merging both _program_map and
_shader_map together with _handleARB map. This is correct for any
OpenGL implementation which supports the GL_ARB_shader_objects
extension, since there is no way to implement this extension correctly
without having shaders and programs in the same namespace.
However, we carefully maintain separate _shader_map and _program_map
for an OpenGL implementation not supporting GL_ARB_shader_objects. In
this case, it's not possible for an application to mix usage (since
none of the ObjectARB functions are guaranteed to exist). And it's
also possible for the implementation to provide separate namespaces
for shaders and programs, so they each need their own map.
Carl Worth [Fri, 16 Nov 2012 20:41:52 +0000 (12:41 -0800)]
trim: Trim swapbuffers calls when --trim-spec=drawing
Previously, the SwapBuffers calls were only getting trimmed if
--trim-spec included "no-side-effects". It was counter-intuitive that
a trim-spec of "drawing" alone would leave all the SwapBuffers calls
in place. So catch them under this trim-spec as well.
Carl Worth [Thu, 15 Nov 2012 04:55:31 +0000 (20:55 -0800)]
trim: Add a new --trim-spec option for fine-grained trimming
This has two benefits:
1. In cases where the dependency analysis goes wrong, using the --trim-spec
option can help identify which portion of the code is misbehaving, (and
allows the user to still get some trim benefit by avoiding the broken
code).
2. The implementation of this change breaks the analysis code up into several
more fine-grained functions, so it should be easier to review and maintain.