The `LD_PRELOAD` mechanism should work with the majority applications. There
are some applications (e.g., Unigine Heaven, Android GPU emulator, etc.), that
The `LD_PRELOAD` mechanism should work with the majority applications. There
are some applications (e.g., Unigine Heaven, Android GPU emulator, etc.), that
shared object that wasn't linked with `-Bsymbolic` flag, so relocations to
those global function pointers get overwritten with the address to our wrapper
library, and the application will segfault when trying to write to them. For
shared object that wasn't linked with `-Bsymbolic` flag, so relocations to
those global function pointers get overwritten with the address to our wrapper
library, and the application will segfault when trying to write to them. For
-**apitrace** will advertise and intercept these GL extensions regardless
-of whether the GL implementation supports them or not. So all you have
+**apitrace** will advertise and intercept these OpenGL extensions regardless
+of whether the OpenGL implementation supports them or not. So all you have
to do is to use these extensions when available, and you can be sure they
will be available when tracing inside **apitrace**.
For example, if you use [GLEW](http://glew.sourceforge.net/) to dynamically
to do is to use these extensions when available, and you can be sure they
will be available when tracing inside **apitrace**.
For example, if you use [GLEW](http://glew.sourceforge.net/) to dynamically
- if (GLEW_GREMEDY_string_marker) {
- glStringMarkerGREMEDY(0, __FUNCTION__ ": enter");
+ if (GLEW_KHR_debug) {
+ glPushDebugGroup(GL_DEBUG_SOURCE_APPLICATION, 0, -1, __FUNCTION__);
- if (GLEW_GREMEDY_string_marker) {
- glStringMarkerGREMEDY(0, __FUNCTION__ ": leave");
+ if (GLEW_KHR_debug) {
+ glDebugMessageInsert(GL_DEBUG_SOURCE_APPLICATION, GL_DEBUG_TYPE_OTHER,
+ 0, GL_DEBUG_SEVERITY_MEDIUM, -1, "bla bla");
Also, provided that the OpenGL implementation supports `GL_KHR_debug`, labels
defined via glObjectLabel() , and the labels of several objects (textures,
Also, provided that the OpenGL implementation supports `GL_KHR_debug`, labels
defined via glObjectLabel() , and the labels of several objects (textures,
commit responsible for a regression.
Below is an example of using tracecheck.py to bisect a regression in the
commit responsible for a regression.
Below is an example of using tracecheck.py to bisect a regression in the
driver hosted on a git repository.
First, create a build script, named build-script.sh, containing:
driver hosted on a git repository.
First, create a build script, named build-script.sh, containing:
generate snapshots for every draw call, using the `-S` option. That is, however,
very inefficient for big traces with many draw calls.
generate snapshots for every draw call, using the `-S` option. That is, however,
very inefficient for big traces with many draw calls.
-A faster approach is to run both the bad and a good GL driver side-by-side.
-The latter can be either a previously known good build of the GL driver, or a
+A faster approach is to run both the bad and a good OpenGL driver side-by-side.
+The latter can be either a previously known good build of the OpenGL driver, or a
reference software renderer.
This can be achieved with retracediff.py script, which invokes glretrace with
reference software renderer.
This can be achieved with retracediff.py script, which invokes glretrace with
manipulating variables such as `LD_LIBRARY_PATH`, `LIBGL_DRIVERS_DIR`, or
`TRACE_LIBGL`.
For example, on Linux:
./scripts/retracediff.py \
manipulating variables such as `LD_LIBRARY_PATH`, `LIBGL_DRIVERS_DIR`, or
`TRACE_LIBGL`.
For example, on Linux:
./scripts/retracediff.py \