0469dd6d55
This patch provides a framework for tracing GLES 1.0 and 2.0
functions. It is missing a lot of features, but here are the
things it accomplishes:
- Stop building the glesv2dbg library, and build the
glestrace library instead.
- Replace the hooks for glesv2dbg with the ones for glestrace.
- Add the basics for the trace library. Currently, this
traces all GL functions, but not all required data is
sent for all the functions. As a result, it will not
be possible to reconstruct the entire GL state on the
host side.
The files gltrace.pb.* and gltrace_api.* are both generated
using the tools/genapi.py script.
Change-Id: Id60a468f7278657f008bc6ea1df01f9bdfecfdd3
52 lines
2.3 KiB
Plaintext
52 lines
2.3 KiB
Plaintext
Design of the GLES Tracing Library
|
|
|
|
Code Runtime Behavior:
|
|
|
|
Initialization:
|
|
|
|
egl_display_t::initialize() calls initEglTraceLevel() to figure out whether tracing should be
|
|
enabled. Currently, the shell properties "debug.egl.trace" and "debug.egl.debug_proc" together
|
|
control whether tracing should be enabled for a certain process. If tracing is enabled, this
|
|
calls GLTrace_start() to start the trace server.
|
|
|
|
Note that initEglTraceLevel() is also called from early_egl_init(), but that happens in the
|
|
context of the zygote, so that invocation has no effect.
|
|
|
|
egl_display_t::initialize() then calls setGLHooksThreadSpecific() where we set the thread
|
|
specific gl_hooks structure to point to the trace implementation. From this point on, every
|
|
GLES call is redirected to the trace implementation.
|
|
|
|
Application runtime:
|
|
|
|
While the application is running, all its GLES calls are directly routed to their corresponding
|
|
trace implementation.
|
|
|
|
For EGL calls, the trace library provides a bunch of functions that must be explicitly called
|
|
from the EGL library. These functions are declared in glestrace.h
|
|
|
|
Application shutdown:
|
|
|
|
Currently, the application is killed when the user stops tracing from the frontend GUI. We need
|
|
to explore if a more graceful method of stopping the application, or detaching tracing from the
|
|
application is required.
|
|
|
|
Code Structure:
|
|
|
|
glestrace.h declares all the hooks exposed by libglestrace. These are used by EGL/egl.cpp and
|
|
EGL/eglApi.cpp to initialize the trace library, and to inform the library of EGL calls.
|
|
|
|
All GL calls are present in GLES_Trace/src/gltrace_api.cpp. This file is generated by the
|
|
GLES_Trace/src/genapi.py script. The structure of all the functions looks like this:
|
|
|
|
void GLTrace_glFunction(args) {
|
|
// declare a protobuf
|
|
// copy arguments into the protobuf
|
|
// call the original GLES function
|
|
// if there is a return value, save it into the protobuf
|
|
// fixup the protobuf if necessary
|
|
// transport the protobuf to the host
|
|
}
|
|
|
|
The fixupGLMessage() call does any custom processing of the protobuf based on the GLES call.
|
|
This typically amounts to copying the data corresponding to input or output pointers.
|