libbacktrace #include's two header files from GCC. Provide minimal
replacements for those files. For filenames.h, declare missing macros
assuming POSIX-style paths. For dwarf2.h, #include system dwarf.h and
declare missing enum tags and define missing enum values as macros.
There was a bool field that was caching results of 'is_backtrace_needed'
lookups. Now that field is gone, and 'is_backtrace_needed' is called
repeatedly. I guess it's not that bad (it boils down to a lookup in an
std::set), but that function was also printing notices for functions
with enabled stack trace recording, and now those messages are printed
repeatedly as well. The following patch removes the notices completely
and slightly cleans up the surrounding code.
Ben Kelly [Mon, 6 May 2013 17:25:15 +0000 (13:25 -0400)]
Use ndk-android-r7 for FirefoxOS builds.
Commit 7445733 added support for FirefoxOS, but appears to have been using
a newer version of the NDK than we typically build with. The codeaurora.org
prebuilts repo we are tracking has not pulled in r8 yet and only provides r7.
For the time being it would be helpful to drop back to r7. Admittedly, we
should probably have a better mechanism for selecting the latest version
available.
Changes from v3: Instead of writing the backtrace as Array, the backtrace is
now recorded as a list of stack frame nodes with optional stack frame details
(the scheme is below).
This patch implements backtrace recording during tracing, and adds support in
'apitrace dump' and QApitrace. Backtrace is obtained via platform-specific
functions (and, internally, in platform-specific format). Then it is parsed to
produce an std::vector of stack frame structs: { char *module, *function,
*filename, *linenumber, *offset } (some fields may be NULL) and is written
into the trace file in the Enter call section as a call detail:
BACKTRACE
FRAME
MODULE "module"
FUNCTION "Foo"
FILENAME "foo.cpp"
LINENUMBER "1234"
OFFSET "0xSDF"
FRAME
FUNCTION "Boo"
// no filename line info available for this frame
END_BACKTRACE
A platform-dependent mechanism is provided to specify a set of traced
calls for which backtraces will be recorded. It is possible to specify
either function names, or prefixes of names by appending a '*' (e.g.
"glUniform*").
On Android the backtrace is retrieved from Dalvik via libdvm functions
imported at runtime.
Function set is specified in /data/apitrace.fnames, one per line.
On Linux the backtrace is retrieved via glibc backtrace(), and will not always
yield filename:linenumber information.
Function set is specified via APITRACE_BT_FUNCTIONS environment variable.
On other platforms, obtaining a backtrace is not implemented by this patch.
Ben Kelly [Sat, 4 May 2013 04:35:37 +0000 (21:35 -0700)]
Fix Android target build on Apple hosts.
Currently CMakeLists.txt forces CMAKE_C_COMPILER to clang whenever
compiling on an APPLE host. Unfortunately, this prevents the
android.toolchain.cmake script from selecting the correct cross
compiler. See [line 1136][].
To avoid this problem, only force clang if ANDROID_NDK is not set. This
is one of the variables used by Android.mk.
Shuang He [Wed, 24 Apr 2013 02:01:15 +0000 (10:01 +0800)]
Add option '--snapshot-format=' to allow write raw RGB directly to stdout
This allows to create h264 video with gstreamer-vaapi very fast, and save much more disk space.
Using PNM format couldn't reach same performance, since PNM decoding seems inefficient in gstreamer.
Following are some experiment data with smokinguns demo 1920x1080 resolution on Ivybridge:
1. With png saving, it runs at around 4.5 FPS, which has compression rate 5.15x against raw RGB data
Reference command:
glretrace -s snapshot/ smokinguns.trace
2. Using PNM with gstreamer-vaapi, which could run at around 9 FPS, which has compression rate
485x (QP dependent) against raw RGB data.
Reference command:
glretrace -s - smokinguns.trace | gst-launch-0.10 fdsrc blocksize=409600 ! queue \
! pnmdec ! videoparse format=rgb width=1920 height=1080 ! ffmpegcolorspace ! queue \
! vaapiupload direct-rendering=0 ! queue ! vaapiencodeh264 ! filesink location=xxx.264
3. With following command that directly write raw RGB stream and encoded into H264 video, it
runs at around 18.5 FPS, which has compression rate 485x (QP dependent) against raw RGB data,
Reference command:
glretrace --snapshot-format=RGB -s - smokinguns.trace | gst-launch-0.10 fdsrc blocksize=409600 ! queue \
! videoparse format=rgb width=1920 height=1080 ! queue ! ffmpegcolorspace ! queue \
! vaapiupload direct-rendering=0 ! queue ! vaapiencodeh264 ! filesink location=xxx.264
v2: Use --snapshot-format= option to specify which format is used to write to stdout output
v3: Use enum for snapshotFormat and add example in README.markdown
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).