Carl Worth [Wed, 29 Aug 2012 21:38:39 +0000 (14:38 -0700)]
trim: Avoid trimming textures when referenced by a framebuffer object
We aren't yet tracking FBOs as their own resource, but we do need to
notice when any texture is referenced by an FBO so that we don't omit
it while trimming. So, notice any textrure referenced by
glFramebufferTexture2D and make the render state depend on this
texture.
Carl Worth [Thu, 16 Aug 2012 18:33:45 +0000 (11:33 -0700)]
trim: Never trim any glBindTexture calls.
This shouldn't be necessary. I've got a case where trimming out the
glBindTexture of an unused texture changes the behavoir, which
shouldn't be the case.
While I'll still try to track down that bug, this patch provides
conservative behavior that hopefully won't break anything. (The only
real downside is the potential of an implementation getting confused
by a glBindTexture with a value that was not returned by
glGenTextures).
Carl Worth [Fri, 17 Aug 2012 03:32:32 +0000 (20:32 -0700)]
trim: Never trim any textures bound within a display list.
This is conservative. The more efficient approach would create a
resource link from the display list to the texture, but that will wait
for when we actually have display-list resources.
Carl Worth [Fri, 17 Aug 2012 01:29:43 +0000 (18:29 -0700)]
trim: Add support for display lists.
The calls specified between glNewList and glEndList need to have
special treatment. For now we do the simplest thing and
unconditionally include all such calls in the trim output.
Eventually we will want to track display-list resources similar to
textures and trim away unused display lists.
Carl Worth [Fri, 17 Aug 2012 15:09:19 +0000 (08:09 -0700)]
trim: Conservatively make shader programs depend on textures
Some shader programs sample textures, so if the shader is included in
the trimmed output the texture needs to be included as well.
We don't have support inside of "apitrace trim" to parse GLSL to find
names of samplers to find these dependencies. Instead, we provide here
a simple heuristic:
In order to sample a texture, the OpenGL program must associate the
name of a texture unit with a location in the shader by calling
glUniform1i (or glUniform1iv). So we can notice whenever texture-unit
names are being passed and create a dependency from the shader to all
texture targets for that unit.
This is conservative on two fronts:
1. The value being passed to glUniformi might only be coincidentally
the same as a texture-unit name and be actually unrelated to
texture sampling.
2. The shader likely doesn't depend on all texture targets, but
again we can't know which without looking inside the shader, so
we associate all of them.
Carl Worth [Fri, 17 Aug 2012 15:06:51 +0000 (08:06 -0700)]
trim: Perform correct state tracking for glActiveTexture
Not all glBindTexture calls are created equal. With calls to
glActiveTexture intervening, calls to glBindTexture are actually
operating on indenpendent texture units.
It's actually quite easy to simple insert the number of the currently
active texture unit into the name of the texture target resource.
Carl Worth [Wed, 15 Aug 2012 23:35:38 +0000 (16:35 -0700)]
trim: Add a new --print-callset option.
This is useful whenever one has a need to manually tweak the trim operation.
Simply run:
apitrace trim --print-callset --frames=<whatever> --calls=<whatever>
as desired. Then take the resulting callset that is printed and run:
apitrace trim --calls=<callset> --exact
This should yield an identical trimming operation. Then this operation
can be tweaked by appending call ranges to the --calls option,
deleting rangess from the --calls option, or by appending a new
--frames option.
Carl Worth [Wed, 15 Aug 2012 05:32:29 +0000 (22:32 -0700)]
trim: Add a --frames option for selecting frames to trim.
This accepts a "frame set" which has syntax identical to the "call
set" of the existing --calls option. So, one could trim to just the
drawing operations of the first 10 frames of a trace with
--frames=0-9/draw.
Carl Worth [Wed, 15 Aug 2012 00:13:30 +0000 (17:13 -0700)]
trim: Abstract common stringstream idioms into shared functions.
Using the new providef, linkf, and unlinkf functions shrinks the code
a bit. It's tempting to provide <stdargs> functions with full
printf-like formatting, but it's really not necessary as of yet.
Carl Worth [Tue, 4 Sep 2012 18:49:13 +0000 (11:49 -0700)]
trim: Fix bug linking incorrect programs to shaders through samplers.
Previously, the code was mapping locations returned by
glGetUniformLocation and looking in the location map to try ot
determine which program to link in a glUniform1i call. This was
entirely bogus, as distinct programs do not have distinct location
spaces.
The correct answer is to simply track the currently active program and
link it to textures being bound to shaders.
Carl Worth [Tue, 14 Aug 2012 22:20:56 +0000 (15:20 -0700)]
trim: Add support for trimming out unused shaders.
The provide/consume analysis framework is finally starting to show
dividends. This is a fairly significant amount of new functionality
for "apitrace trim" yet it requires relatively little new code.
Carl Worth [Tue, 14 Aug 2012 21:11:19 +0000 (14:11 -0700)]
trim: Drop unused textures while trimming.
We introduce a new dependencies map so that some resources can depend
on other resources, effectively providing a tree of calls that need to
be included when the user requests a particular call be preserved in
the trim.
For example, a SwapBuffers call depends on the "framebuffer".
A rendering operation makes "framebuffer" depend on "render-state".
Enabling texturing makes "render-state" depend on "texture-target-FOO".
Binding a texture makes "texture-target-FOO" depend on "texture-X".
Uploading a texture makes the current call provide "texture-X".
Creating a texture makes the current call provide "texture-X".
This way, if a particular SwapBuffers call is included in the trimmed
output, all of the above will be included. Otherwise, if a SwapBuffers
is trimmed, then the "framebuffer" dependencies will be cleared and
none of the above calls will be included in the trimmed output.
Carl Worth [Mon, 13 Aug 2012 21:35:43 +0000 (14:35 -0700)]
trim: Trim most drawing operations outside of the user-specified range
Care is taken to consider a glBegin/glEnd block as a single drawing
operation, (so that it will enitrely included or entirely trimmed).
We're also careful to avoid trimming any drawing operation when there
are active side effects (other than rendering to the default
framebuffer). For example, if there is an active binding of
GL_FRAMEBUFFER or GL_DRAW_FRAMEBUFFER to any buffer object, or if we
are withing a glBeginTransformFeedback/glEndTransformFeedback block;
in any of these cases the drawing operation will not be trimmed.
Carl Worth [Sat, 11 Aug 2012 18:46:54 +0000 (11:46 -0700)]
trim: Add a more condensed usage message for error cases.
When explicitly asking for help, ("apitrace help trim" or "apitrace
trim --help"), the complete help message is still provided.
But when an error case triggers a usage message, (such as an invalid
command-line argument), a more compact usage message is provided so as
to not overwhelm the error message (such as "invalid argument:
--foo").
Carl Worth [Sat, 11 Aug 2012 18:33:12 +0000 (11:33 -0700)]
trim: Prune uninteresting calls while trimming (unless --no-prune is passed)
Examine the CALL_FLAG_UNINTERESTING flag and leave out these calls
when trimming. These calls are generally the calls that have no side
effects, (such as query functions). Some calls without side effects
might be considered interesting, (such as glGetError returning a
non-zero error).
This pruning behavior can be avoided by passing the new --no-prune
option (or the new --exact option which is identical to passing both
--no-prune and -no-deps).
Carl Worth [Tue, 4 Sep 2012 23:48:00 +0000 (16:48 -0700)]
trim: Complain if given extraneous arguments.
Previously additional arguments were silently ignored, (which can lead
to confusion if the user expects to be able to specify a bare callset
on the command line rather than specifying a --calls option).
Carl Worth [Fri, 10 Aug 2012 17:15:30 +0000 (10:15 -0700)]
trim: Add framework for performing dependency analysis while trimming
The current analysis is as brain-dead as possible. All calls are
interpreted as affecting the current "state" resource, and all calls
are also interpreted as depending on the current "state". In other
words, no calls at all will be trimmed. Obviously, this is not useful
analysis, but all the framewok is now present for easily doing more
interesting things.
A new --no-deps option is now made available to "apitrace trim" so
that users can avoid all dependency analysis and still get the prior
behavior where only calls explicitly included in the --calls option
are included in the trim output.
Carl Worth [Mon, 20 Aug 2012 16:45:27 +0000 (09:45 -0700)]
cli: Add a simple "apitrace replay" sub-command.
This calls out to glretrace in order to replay a trace. Currently it
only supports the -w,--wait option, (and not yet any of the profiling
support).
With this command and the existing "apitrace dump-images", we're quite
close to being able to relegate glretrace to an implementation detail
used by the apitrace program, (such that soon, it won't be necessary
to provide glretrace on the user's PATH).
Carl Worth [Sun, 12 Aug 2012 23:36:48 +0000 (16:36 -0700)]
dump-images: Execute glretrace from source dir when running uninstalled
Previously, we've had code to carefully find wrappers and scripts
relative to an apitrace binary being run from an uninstalled
directory. This is extremely useful while testing an experimental
feature before installing said experimental code.
Similarly, provide a findProgram function to do the same thing for an
executable program and use it within "apitrace dump-images" when
invoking glretrace.
Carl Worth [Sun, 12 Aug 2012 23:01:09 +0000 (16:01 -0700)]
Move trace::findWrapper to trace_resource.cpp
It's not actually used outside of trace_tools_trace.cpp, but it is so
similar to the existing trace::findScript in trace_resource.cpp that
there are benefits to having them defined in the same file.
Carl Worth [Sun, 12 Aug 2012 19:44:50 +0000 (12:44 -0700)]
glretrace: Use getopt rather than manual parsing of command-line options
This allows for better consistency with other apitrace command-line
interface. It also provids for several new full-name options where
previously only a single-letter option was available,
(--snapshot-prefix for -s, --verbose for -v, et.).
We use getopt_long_only here to maintain compatibility with the older
style of long options with one dash (-core) as well as providing the
double-dash version )--core).
It would now be quite convenient to regularize the command-line
interface to glretrace in several ways. None of these are performed in
this commit to avoid breaking compatibility with existing scripts,
etc.:
* Combine related options under a single name (--pcpu and --pgpu
could be something like --profile=cpu,gpu).
* Combine options with the same meaning that would never be used
independently. Snapshot generation and snapshot comparison are
different modes. Meanwhile, prefix selection and call selection
should apply identically to either mode. So both modes can use a
single set of options (--prefix and --calls) rather than having
separate --snapshot-prefix and --snapshot options.
Carl Worth [Sun, 12 Aug 2012 23:48:10 +0000 (16:48 -0700)]
Move static boolOption function to trace::boolOption
Other programs will also want to be able to parse Boolean command-line
options, so we should share this code in order to easily get
consistent behavior.