valvesoftware/vogl

OpenGL capture / playback debugger.

vogl

NOTE

April 16, 2014: Vogl history has been completely and utterly trounced. The original repository had an entire chroot build system that most folks weren't interested in. A few contributors (thanks Carl & Sir Anthony) took the time to build a much smaller source only vogl repository which we've replaced the original one with.

A separate chroot repository (which will build this source repository) is now here:

https://bitbucket.org/raddebugger/vogl_chroot

Warning

This project is alpha^2. If you are up for suffering through a bit of pain with early releases, please jump in - we'd love to have your help...

Dependencies

The chroot configuration script should be a good reference for vogl dependencies. It is located here:

https://bitbucket.org/raddebugger/vogl_chroot/src/master/bin/chroot_configure.sh?at=master

The build dependencies for ubuntu (14.04) can be installed using the following:

sudo apt-get install build-essential pkg-config cmake libx11-dev \
                     zip wget libtinyxml-dev liblzma-dev libunwind8-dev \
                     libturbojpeg libdwarf-dev mesa-common-dev qt5-qmake\
                     freeglut3-dev qt5-default libqt5x11extras5-dev git \
                     libsdl2-gfx-dev libsdl2-image-dev libsdl2-ttf-dev libjpeg-turbo8-dev

Get Source and Build

Linux

git clone https://github.com/ValveSoftware/vogl.git  
mkdir -p vogl/vogl_build/release64 && cd $_  
cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_X64=On ../..
make -j 10

The binaries are placed in the vogl/vogl_build directory.

For debug builds, use "-DCMAKE_BUILD_TYPE=Debug"
For 32-bit builds, use "-DBUILD_X64=Off"

Windows

git clone https://github.com/ValveSoftware/vogl.git
mkdir -p vogl\vogl_build\x64
cd vogl\vogl_build\x64
cmake -DQt5_DIR="C:\Qt\5.3\msvc2013_64_opengl\lib\cmake\Qt5" -G "Visual Studio 12 2013 Win64" ..\..
cd ..\..\..\
mkdir -p vogl\vogl_build\win32
cd vogl\vogl_build\win32
cmake -DQt5_DIR="C:\Qt\5.3\msvc2013_opengl\lib\cmake\Qt5" -G "Visual Studio 12 2013" ..\..

Note: The path to Qt5 might need to be adjusted depending on your install location. After compiling with Visual Studio, the binaries are placed in the vogl\vogl_build\Release (or Debug) directory.

Mac OS X

Install the required build dependencies using Homebrew:

brew install pkg-config cmake sdl2 qt5 xz jpeg-turbo tinyxml

Then build with:

git clone https://github.com/ValveSoftware/vogl.git

mkdir -p vogl/vogl_build/mac
cd       vogl/vogl_build/mac

cmake ../.. -DCMAKE_PREFIX_PATH=/usr/local/Cellar/qt5/5.3.2/
make

Note: the Mac port is not yet functional.

Capturing

cd vogl_build
VOGL_CMD_LINE="--vogl_tracefile vogltrace.glxspheres64.bin" LD_PRELOAD=$(readlink -f libvogltrace64.so) ./glxspheres64  

For capturing Steam games, please see the vogl_trace.sh script in the chroot repository:

https://bitbucket.org/raddebugger/vogl_chroot/src/master/bin/src/sl.cpp?at=master

We are currently working on making it much easier to launch and profile Steam apps.

Replay

./voglreplay64 play vogltrace.glxspheres64.bin

or launch vogleditor64 and open trace file.

QtCreator tagging and building

See qtcreator/qtcreator.md file: qtcreator.md

Vogl Dev List

http://lists.voglproj.com/listinfo.cgi/dev-voglproj.com

Useful Links

Vogl Wiki

• https://github.com/ValveSoftware/vogl/wiki

OpenGL documentation/references

• 4.x: http://www.opengl.org/sdk/docs/man/
• 3.3: http://www.opengl.org/sdk/docs/man3/
• 2.1: http://www.opengl.org/sdk/docs/man2/

Specifications

• 4.0: http://www.opengl.org/registry/doc/glspec40.core.20100311.pdf
• 3.3: http://www.opengl.org/registry/doc/glspec33.core.20100311.withchanges.pdf
• 2.1: http://www.opengl.org/documentation/specs/version2.1/glspec21.pdf

License and Credits

Vogl code is MIT licensed.

Copyright 2013-2014 RAD Game Tools and Valve Software

All Rights Reserved.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

libbacktrace is BSD licensed. Libbacktrace license.

apitrace is MIT licensed: Apitrace license.

Loki is MIT licensed: Loki license.

Valgrind header files are BSD-style licensed: Valgrind header files.

GL header files are MIT licensed: GL header files.

glxspheres (from VirtualGL) is wxWindows Library licensed: wxWindows Library License.

SDL is zlib licensed: zlib license.

stb files (from Sean Barrett) are public domain.

TinyXML-2 is zlib licensed: zlib license.

vogl's Issues

vogleditor64 segfaults when creating state snapshot

Hi,

when loading this trace (https://www.dropbox.com/s/27h0cgoil7gz9wn/trace2_trim.bin) in vogleditor64 (built from f56fdbb) and expanding frame 98 and clicking on the first API call the application segfaults.

I can go to earlier frames like (15 or 20) and click on any API call and have them marked with the blue indicator, but the last frames make the application crash.

Full GDB Backtrace:
https://gist.github.com/blackout24/9633330

vogleditor: timeline improvements

-needs ability to pan and zoom
-add ability to click on timeline and jump to associated API call

Goals of VOGL

What are the goals of VOGL compared to alternatives? I think this should be clearly stated as it may help motivate some people to participate in contribution (including myself ;)).

vogleditor: timeline does not display api calls which are nested in the tree control

After pull request #49, which added support for nesting calls in glPush/PopDebugGroup, I noticed that all the nested calls are not appearing in the timeline.

Screenshot appears in vogleditors color buffers view

Hi,

when opening a trace from ExtremeTuxRacer in vogleditor64 and clicking on a call and after that on a second call a part of the desktop appears in the framebuffer view.

Trace: https://www.dropbox.com/s/hsva9s89uz02yb9/etr_trim.bin

I was able to reproduce this 5 times with various calls.

Attempting to build without chroot fails.

I'm attempting to build the vogl without chroot scripts. Using Ubuntu 13.10 (Saucy).

Steps

I've installed the following packages (grab what looked to be the appropriate list of dependencies from the chroot scripts):
libturbojpeg libjpeg-turbo8-dev libglfw-dev debootstrap schroot p7zip-full libunwind8-dev libunwind8 build-essential g++-4.8 libx11-dev mesa-common-dev libgl1-mesa-dev libglu1-mesa-dev freeglut3-dev zip libegl1-mesa-drivers wget libncurses5-dev libgpm-dev libreadline6-dev libdw-dev libxrandr-dev libxi-dev libxxf86vm-dev toilet time libgl1-mesa-dri:i386 liblzma-dev

Steps (from the vogl source directory),
cd src vi build_options.cmake
Change march to be core2 instead of corei7
mkdir test_build cd test_build cmake ../ -G"Unix Makefiles" -DBUILD_X64=On -DCMAKE_BUILD_TYPE=debug -DCMAKE_VERBOSE=On > cmake.log
cmake.log

make all -k > make_vogl.log 2>&1
make_vogl.log

Issues 1 (libbacktrace)

Missing a library to be linked against (lzma); This can be fixed by adding it as a link target (correct the linking in libbacktrace);

diff --git a/src/libbacktrace/CMakeLists.txt b/src/libbacktrace/CMakeLists.txt
index 544039a..367ee91 100644
--- a/src/libbacktrace/CMakeLists.txt
+++ b/src/libbacktrace/CMakeLists.txt
@@ -176,7 +176,7 @@ add_library (backtrace STATIC EXCLUDE_FROM_ALL
 target_link_libraries(backtrace voglcore)

 find_library(LIBUNWIND_LIBRARY libunwind.a)
-target_link_libraries(backtrace ${LIBUNWIND_LIBRARY})
+target_link_libraries(backtrace ${LIBUNWIND_LIBRARY} lzma)

 set_target_properties (backtrace PROPERTIES
     COMPILE_FLAGS "${CMAKE_SHARED_LIBRARY_C_FLAGS}"

Issues 2 (voglreplay64 and other targets)

Missing symbols; this appears to be due to missing a custom patch to libunwind
unw_backtrace_skip, (unsure, but my guess is this patch needs to be applied upstream.)

Issue 3 (gltests/msaa_depthstencil)

src/gltests/msaa_depthstencil/main.c
error: ‘for’ loop initial declarations are only allowed in C99 mode
for (uint i = 0; i < 512; i++)

This can be fixed by adding -std=c99 to the compile command. Additional the type uint isn't available, this can be added with a typedef (or by using GLuint).

diff --git a/src/gltests/msaa_depthstencil/CMakeLists.txt b/src/gltests/msaa_depthstencil/C
index 9beb067..5de063b 100644
--- a/src/gltests/msaa_depthstencil/CMakeLists.txt
+++ b/src/gltests/msaa_depthstencil/CMakeLists.txt
@@ -5,7 +5,7 @@ include("${SRC_DIR}/build_options.cmake")

 aux_source_directory(. SRC_LIST)

-add_definitions("-Wno-unused-variable")
+add_definitions("-Wno-unused-variable -std=c99")

 add_executable(${PROJECT_NAME} ${SRC_LIST})

diff --git a/src/gltests/msaa_depthstencil/main.c b/src/gltests/msaa_depthstencil/main.c
index 459156e..0da5983 100644
--- a/src/gltests/msaa_depthstencil/main.c
+++ b/src/gltests/msaa_depthstencil/main.c
@@ -190,6 +190,7 @@ int main( int argc , char* args[] )
     }

     float f = 0.0f;
+    typedef unsigned int uint;
     uint s = 0;

     while( running )

Issue 4 (vogltrace)

The library libturbojpeg.a is not compiled with the right flags (the Ubuntu version is obviously not correct). Forcing it to switch to libjpeg causes undefined references to tjInitCompress, tjCompress2, tjDestroy, tjFree;

/usr/bin/c++  -fPIC -g -Wall -Wextra -fno-omit-frame-pointer -march=core2 -Wno-unused-parameter -Wno-unused-function -fno-strict-aliasing -fno-math-errno -fvisibility=hidden -Wno-unused-local-typedefs -DVOGL_REMOTING -g -O0 -D_DEBUG -Wl,--no-undefined -Wl,-Bsymbolic -Wl,--version-script=/home/gking/Programming/C++/vogl/src/vogltrace/libvogltrace_linker_script.txt -shared -Wl,-soname,libvogltrace64.so -o /home/gking/Programming/C++/vogl/vogl_build/bin/libvogltrace64.so CMakeFiles/vogltrace.dir/vogl_trace.cpp.o CMakeFiles/vogltrace.dir/vogl_intercept.cpp.o CMakeFiles/vogltrace.dir/vogl_remote.cpp.o CMakeFiles/vogltrace.dir/__/common/channel.cpp.o CMakeFiles/vogltrace.dir/__/common/mtqueue.cpp.o CMakeFiles/vogltrace.dir/__/common/channelmgr.cpp.o CMakeFiles/vogltrace.dir/__/common/toclientmsg.cpp.o CMakeFiles/vogltrace.dir/__/common/pinggame.cpp.o ../libbacktrace/libbacktrace.a ../voglcommon/libvoglcommon.a ../voglcore/libvoglcore.a -lpthread -ldl /usr/lib/x86_64-linux-gnu/libX11.so -Wl,-Bstatic -lturbojpeg -Wl,-Bdynamic -lrt ../libbacktrace/libbacktrace.a ../voglcore/libvoglcore.a -lpthread -Wl,-Bstatic -lunwind -Wl,-Bdynamic -llzma -lrt 
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libturbojpeg.a(libturbojpeg_la-turbojpeg.o): relocation R_X86_64_32 against `.data' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libturbojpeg.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [/home/gking/Programming/C++/vogl/vogl_build/bin/libvogltrace64.so] Error 1
make[2]: Target `vogltrace/CMakeFiles/vogltrace.dir/build' not remade because of errors.
make[1]: *** [vogltrace/CMakeFiles/vogltrace.dir/all] Error 2

This will probably require an upstream change in Ubuntu.

System Details

uname -a returns Linux bender 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
glxinfo
steam info

Error with glDrawElements in display lists

When gathering trace data on an application that compiles vertex arrays to display lists, vogl spits out:

(vogltrace) Error: vogl_should_serialize_call: Called GL func glDrawElements is not currently supported in display lists! The replay will diverge.

As far as I'm aware, OpenGL 2.0 supports this. I'm guessing display lists just haven't gotten much attention yet in vogl since they were deprecated in OpenGL 3.

RFE: state change table

It'd be nice if vogl could generate something like the table shown on slide 54 of the nVidia "Beyond Porting" talk from Steam DevDays.

cmake can't find Qt 4

Commit eb3dfe9 removed QT_QMAKE_EXECUTABLE definition.

This breaks the build:

CMake Error at /usr/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (message):
  Could NOT find Qt4 (missing: QT_QMAKE_EXECUTABLE QT_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:291 (_FPHSA_FAILURE_MESSAGE)
  /usr/local/share/cmake-2.8/Modules/FindQt4.cmake:1223 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  vogleditor/CMakeLists.txt:5 (find_package)

If the commit is reverted, then the build is fixed.

vogltrace/vogl_intercept.cpp:4816:34: error: ‘TJFLAG_FASTDCT’ was not declared in this scope

TJFLAG_FASTDCT flag has been introduced in turbojpeg 1.2.1, so vogl will fail to compile on older versions of library. I guess that it would be nice to check with CMake, whether needed version of turbojpeg lib is available on system. CMake configuration step will fail then and will inform user that more recent library version is needed.

Doc updates for new binary structure

Some of the docs in the wiki still refer to binaries such as voglreplay64 which no longer exist and are now instead vogl64 replay. I'm sure there are more.

Add Steam 2ft and 10ft traces to regression tests

-this can be done once 10ft MakeCurrent bug is fixed

rubinius

Segfault when tracing GLTron and pressing "Start Game" in menu

When tracing gltron with:

VOGL_CMD_LINE="--vogl_debug --vogl_dump_stats --vogl_tracefile /tmp/vogltrace.bin --vogl_disable_client_side_array_tracing --vogl_pause" LD_PRELOAD=/usr/lib/libvogltrace64.so gltron

The game starts and shows the menu. After pressing "Start Game" the process segfaults, but still writes a trace to disk which is replayable to that point.

Terminal Output: https://gist.github.com/blackout24/9714254
GDB Backtrace: https://gist.github.com/blackout24/9714195

I can recompile vogl with -O0 for better backtrace if that's needed.

Repository size unexpectedly large

I checked out repository just now (with --depth 1) and found it unreasonably big (about 230Mb while vogl code is about 30Mb itself). You have a lot of 3rd party code in it which can be replaced by submodules or cmake requirements (with fixed versions if it is important), also you keep files generated during build in the tree. Do you really want to keep local copies of this stuff (the only explanation I can think of is distribution issues)? I'm planning to make a series of changes to reduce repository size, do you have any complaints about it?
First thing I want to know, is ogl-samples shaders (main difference only in shaders) modified on purpose or it is just old? Probably, the best way is to fork original project and replace current directory with the submodule with this fork as a target.

voglgen

Is there any major reason you chosen c++ as primary language for voglgen? I'm planning to write python version of inc generator using khronos generator for xml spec for GLSL-Debugger. Do you mind to switch to some generalized version of this? Generated files are pretty similar now, so it'll not require much work to do.

Is there a more convenient way to contact you to discuss vogl internals than using the github tickets? I think, I'll have many questions in the nearest future.

massive-octo-spice

massive-octo-spice

Recommended pronunciation of vogl's name is iffy

While I'm very pleased to see vogl, I'm worried about the pronunciation recommended during the Steam Dev Days talk (rhymes with boggle and goggle) because it's at odds with the intuitive pronunciation rules that undergird English.

The stronger someone's grasp of English, the more likely they are to pronounce "vogl" using the same first syllable as in "vogue".

That's because one of the underlying pronunciation rules is that, when a syllable ends on a vowel, you read it as a long vowel. [1]

That's why "boggle" and "goggle" double up the "g": So the first syllables can be "bog" and "gog" rather than "bo" and "go".

Dependency of chroot_build.sh from user's shell being bash

My default shell is zsh, which is not installed by default by debianboostrap. This caused the chroot_configure.sh to not be executed because schroot couldn't find a shell for launching the script. Solved locally by installing zsh into the chroot env, but I suppose it could be solved as well by making sure the script is run through bash or by not inheriting the user's environment in the chroot env.

GL4.x support

a) Add program pipeline objects
b) Add parser for new Khronos XML spec so we can get new 4.x APIs
c) Implement more tests for all GL4.x texture types

Missing copyright notices from apitrace

I'm disappointed to see that vogl cherry-picked several pieces of source code from apitrace without including a single copyright notice.

Please re-read the apitrace license, in particular the paragraph that says:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

and comply with the licensing terms.

Also, the comment in

vogl/src/voglcore/vogl_platform.cpp

Line 128 in bd9ebcf

// Derived from apitrace, but this code appears to have been copied around and tweaked from multiple sources:

is untrue. The apitrace signal handler code was not copied. These URLs are references for similar signal handlers used to give an idea of what is or not normal/acceptable behavior. I would appreciate if you would remove this baseless comment.

using on fedora/custom GNU/Linux distro

How do we use vogl on fedora/custom GNU/Linux distro?

I have had a pesky bug on dota2 with the mesa GL driver for a little while (fedora rawhide). A crash in engine.so. Maybe vogl can help narrowing down the bug.

Missing transparency in texture when replaying Xonotic trace

Hello,

when replaying a capture of Xonotic the plant textures are black instead of transparent.
This scene can be found on the map "Solarium".

https://www.dropbox.com/s/xy52z2afgczjmdv/missing_transparency-trace.bin
The grass texture is texture 295 in the trace, when opening with vogleditor.

This is a 64 Bit trace.

This is my ~/.xonotic/data/config.cfg
https://gist.github.com/blackout24/9655545#file-config-cfg

Resizing of vogleditor window is slow depending on trace size

Hi,

when I load this 60 MB trace file (https://www.dropbox.com/s/27h0cgoil7gz9wn/trace2_trim.bin) redrawing of a resized window takes about 100 ms.

When I load this 80 MB trace file
(https://www.dropbox.com/s/lbhj8qhw3icximu/trace_trim.bin) redrawing takes about a second.

When I load this 250 MB trace file
(https://www.dropbox.com/s/0st9wcht1nipdag/trace.bin) redrawing takes about 4-5 seconds.

Specs:

Intel Core i7 2600K 4.5 Ghz
8 GB RAM
SATA III SSD
GTX 580

Complete quoting for parameters of some CMake commands

Some parameters (like "${CMAKE_CURRENT_BINARY_DIR}" and "${SRC_DIR}") are passed to CMake commands in your build scripts without enclosing them by quotation marks. I see that these places will result in build difficulties if the contents of the used variables will contain special characters like spaces.

I would recommend to apply advices from a Wiki article.

Crash tracing program that uploads texture data from pixel buffer

Example:
https://gist.github.com/Daft-Freak/f3dd53c93c87b8ee0680

[Minor Issue] test-benchmark_sphere fails without mars.bmp

Minor issue: attempting to run :

./test-benchmark_sphere64 
ERROR: getBitmapImageData - %s not found mars.bmp.
Segmentation fault (core dumped)

I just downloaded mars.bmp; placed this in the same directory of the binary; and it runs properly. Note: size of the bmp is 8.9MB.

Result Window is below:

vogl_entrypoints.cpp memory hog in 32-bit mode

Summary
Compiling vogl_entrypoints.cpp in 32-bit mode on a 64-bit machine eats up all memory before the compile is killed by OOM killer. This happens with gcc 4.8.2.

Details
Compiling vogl_entrypoints.cpp in 64-bit mode takes a lot of time, but otherwise it compiles fine. However, when compiling with gcc -m32 it eats ~14GB of memory before gcc is killed. It has been suggested [1] that passing -fno-var-tracking should fix this issue (as it is already used in the sources).

However, it seems that gcc ignores this option. This can be tested in a following way:

1. remove -O2 from the compiler command line
2. get a list of what optimizations are enabled with -O1:
   g++ -Q -O1 --help=optimizers | grep enabled | cut -d"[" -f1 | tr -d '\n'
3. test compilation while manually enabling optmizations:
   1. pass all optimizations from the list to gcc when compiling entrypoints => compilation gets stuck
   2. pass all optimizations except -fvar-tracking => everything compiles fine
   3. pass -O1 -fno-var-tracking => compilation gets stuck

Solution
So far I found only one possible solution and that is disabling the optimizations for the said file completely, ie. replace -fno-var-tracking in src/voglcommon/CMakeLists.txt with -O0

References
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59868
[2] #9

'Function "glXCreatePbuffer" not yet in function whitelist'

No offscreen rendering possible yet, I'd still like to use vogl to debug my application.

[Feature Request] Use pbuilder instead of custom chroot

Based upon the chroot jail scripts it appears that this could be converted over to a pbuilder Ubuntu/Debian build and packaging setup. It allows for rapid updating of the chroot envirnoment. Further it allows for building of architecture and distribution chroot jails.

[Minor Issue][Warnings] Clang-3.5

I'm compiling vogl with clang-3.5 toolchain (using debs from llvm+clang). I do the following
CC=clang CXX=clang++ cmake ../../ -DCMAKE_BUILD_TYPE=debug -DVOGL_ENABLE_ASSERTS=On

Not of huge importance, there are a huge number of warnings with regards to using C-style casts (this is more just to provide documentation for people trying to compile this with a more recent version of clang). For example,

vogl/src/voglcore/vogl_vector.h:732:50: warning: use of
      old-style cast [-Wold-style-cast,Semantic Issue]
                    VOGL_ASSERT_OPEN_RANGE(i, 0, (int)m_size);

Most of these warnings appear not to be huge importance.

This warning however appears to signal a semantic issue (infinite-recursion) according to the compiler:

In file included from vogl/src/libbacktrace_test/libbacktrace_test.cpp:32:
In file included from vogl/src/voglcore/vogl_json.h:703:
vogl/src/voglcore/vogl_json.inl:809:5: warning: all paths
      through this function will call itself [-Winfinite-recursion,Semantic Issue]
    {

[Minor Issue] test programs should check that SDL_GLContext is valid.

This is a minor issue.

I'm currently using the Mesa drivers, and as such, attempting to create a context of 3.2 is not possible; glxinfo returns

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.2.0-devel
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)

The programs in src/gltests should check that the SDL_GLContext is not NULL.

#ifndef NDEBUG
#include <assert.h>
#endif

and

SDL_GLContext maincontext = SDL_GL_CreateContext(window); /* Our opengl context handle */
#ifndef NDEBUG
assert(maincontext != NULL);//SDL couldn't create a valid OpenGL context;
#endif

build failure on ubuntu 14.04

Thought i'd point this one out - I suspect there is a missing dependency in linking:

[ 38%] Built target backtracevogl
Scanning dependencies of target libbacktrace_test
[ 39%] Building CXX object src/libbacktrace_test/CMakeFiles/libbacktrace_test.dir/libbacktrace_test.cpp.o
Linking CXX executable ../../../../libbacktrace_test64
../libbacktrace/libbacktracevogl.a(btrace.cpp.o): In function module_info_init_state': /home/bms20/vogl/src/libbacktrace/btrace.cpp:271: undefined reference toelf_get_uuid'
collect2: error: ld returned 1 exit status
make[2]: *** [../../libbacktrace_test64] Error 1
make[1]: *** [src/libbacktrace_test/CMakeFiles/libbacktrace_test.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Linking CXX executable ../../../../vogltest64
Linking CXX executable ../../../../voglgen64
[ 39%] Built target vogltest
[ 39%] Built target voglgen
make: *** [all] Error 2
bms20@arthas:~/vogl/vogl_build/bin/release64$

Witcher 2 issues

1. During capture: (vogltrace) Warning: GL error GL_INVALID_ENUM occurred sometime before this function was called. This error has been latched by the tracer onto the tracer's context shadow struct. This error will be reported to the caller the next time glGetError() is called, and will mask any GL error returned by that future call.
2. Libunwind crashes. Need to specify --vogl_backtrace_no_calls.
3. Fails with xterm. Need to specify --no-xterm w/ steamlauncher.
4. Several GL_INVALID_OPERATION warnings during replay.
5. Assert during replay: ../../../vogl/src/voglcommon/vogl_gl_replayer.h(548): Assertion failed: "hash_map.search_table_for_value_get_count(handle) <= 1"

Cannot open a trace in the editor

I'm on Ubuntu (Linux 3.8.0-37-generic #53~precise1-Ubuntu x86_64). I followed the instructions from the readme to build everything for both i386 and amd64. My GPU is an ATI FirePro V5800.

I created a couple of traces (for 32 bits) with the steamlauncher.sh script, first of my own app, and then of glxspheres32.

For all traces, I can replay them fine with voglreplay32.

However if I try opening them up with vogleditor32, I get this error:

vogl_trace_file_writer::open (71): Prepping trace file "vogleditor_session.bin"
vogl_trace_file_writer::open (124): Finished opening trace file "vogleditor_session.bin"
sys_alloc: mmap() of 364544 bytes failed! Reason: Operation not permitted (errno 0x1)
[1]    3336 abort (core dumped)  ~/src/vogl/vogl_build/bin/vogleditor32

If I launch the editor with (shiver) sudo, I get a slightly different error:

vogl_trace_file_writer::open (71): Prepping trace file "vogleditor_session.bin"
vogl_trace_file_writer::open (124): Finished opening trace file "vogleditor_session.bin"
sys_alloc: mmap() of 364544 bytes failed! Reason: Cannot allocate memory (errno 0xc)

izz - okt - Tribble

System becomes unresponsive when trying to open a trace in the editor

I'm on Ubuntu (Linux 3.8.0-37-generic #53~precise1-Ubuntu x86_64). I followed the instructions from the readme to build everything for both i386 and amd64. My GPU is an ATI FirePro V5800.

I created a couple of traces with the steamlauncher.sh script, first of my own app (32 bits), and then of glxspheres32 and of glxspheres64.

All traces are replayed fine through voglreplay32/64.

However if I try opening any trace in vogleditor64, my system becomes unresponsive, the hard drive spins to no end and I have to hard reset.

I cannot try the 32 bits editor because of a crash, reported in a separate issue.

state snapshotting/restoring. AMD driver: Fix backbuffer/frontbuffer saving/restoring

This works fine on NV but not on AMD

Writing traces to anything but tmpfs causes hickups in gameplay

Hello,

when creating traces on my HDD the gameplay stops for about half a second every 10 seconds or so.

Tracing to the SSD shows the same issue. When replaying these traces the hickups are not visible in the replay. I monitored my system resources and did not notice anything unusual with RAM and CPU usage.

When I point the output file to /tmp I can play without hickups, but since its size is only half my RAM the trace aborts when /tmp is full.

https://gist.github.com/blackout24/9655278

I was able to reproduce this with two games (Sauerbraten and Xonotic).

vogleditor looks for files in the wrong place. Ubuntu

I generated a trace file in the build directory, for the application glxspheres64.
But when I tried to open it in vogleditor, with the open dialog, it tries to find it in

/home/ian/.local/share/vogleditor64/sessions/vogltrace.glxspheres64-trim.bin

Generating the trace file with vogleditor, makes the same error occur, but then if I try to open it again, it now works. Now it looks for the file like so

/home/ian/.local/share/vogleditor64/sessions/../../../../Development/vogl/vogl/vogl_build/vogltrace.glxspheres64-trim.bin

This is on Ubuntu 64bit, Nvidia proprietary drivers, kernel 3.11.0-18-generic

Search in the editor really slow

I can open and work fine with traces in the 32 bits editor (on Linux Ubuntu). However as soon as I type any letter inside the search box, the application becomes unresponsive. (One) CPU goes to 100% and it takes ages to get the application back. This happens for me even with smallish traces, around 10 MB. Eventually the search works, but as it is now for me this feature is unusable.

Move to using small hook shim

Our preloaded dso pulls in a ton of dependencies, uses a lot of memory, and generally does far too much work in the game process. And if the game crashes we're stuck trying to flush things in signal handlers.

Going to move to using a small C only OGL shim which only captures the GL call stream data and forwards to a separate process.

Current dependency list is pretty crazy:

mikesart@mikesart-petra:~/dev/voglproj/vogl_chroot.bitbucket/vogl (master)$ ldd ../vogl_build/libvogltrace64.so                                                                     
        linux-vdso.so.1 =>  (0x00007fff3bffe000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3aa7ee9000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3aa7ce5000)
        libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007f3aa7adc000)
        libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007f3aa78c0000)
        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f3aa758b000)
        libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f3aa7378000)
        libturbojpeg.so.0 => /usr/lib/x86_64-linux-gnu/libturbojpeg.so.0 (0x00007f3aa711e000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3aa6f16000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f3aa6cf3000)
        libSDL2-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007f3aa69ee000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3aa66ea000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3aa63e3000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3aa61cd000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3aa5e07000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3aab0bc000)
        libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f3aa5c01000)
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f3aa59e2000)
        libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f3aa56f1000)
        libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007f3aa54ed000)
        libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f3aa52a4000)
        libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f3aa5099000)
        libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f3aa4e96000)
        libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f3aa4c86000)
        libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f3aa4a7b000)
        libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1 (0x00007f3aa4877000)
        libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f3aa4671000)
        libwayland-egl.so.1 => /usr/lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x00007f3aa446e000)
        libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007f3aa4261000)
        libwayland-cursor.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007f3aa4059000)
        libxkbcommon.so.0 => /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f3aa3e1e000)
        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f3aa3c1a000)
        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f3aa3a13000)
        libpulsecommon-4.0.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-4.0.so (0x00007f3aa37ac000)
        libjson-c.so.2 => /lib/x86_64-linux-gnu/libjson-c.so.2 (0x00007f3aa35a0000)
        libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f3aa335b000)
        libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f3aa3151000)
        libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f3aa2f4a000)
        libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f3aa2d42000)
        libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f3aa2b37000)
        libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f3aa28cf000)
        libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f3aa26c9000)
        libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f3aa24ae000)
        libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f3aa227d000)
        libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f3aa1dae000)
        libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f3aa1b80000)
        libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f3aa1977000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f3aa175c000)

Leaflet

otthon

Hotkey support

Need to hook the various XNextEvent functions to add hotkey support to vogl.

Probably should have the ability to specify the hotkey on the command line or a config file.

If anyone has any comments, suggestions, please let me know. I'm hoping to start looking at this in ~7 - 10 days. Thanks!

Planetary Annihilation Bugs

From Jorgen:

I tried running the latest vogl from github (built using the
vogl_chroot) on our game, Planetary Annihilation, under Linux 64-bit.

It succeeded in capturing & playing back, but there's a lot of spew in
the console, and there are some (very obvious) rendering artifacts.

Here're the commands I ran:

VOGL_CMD_LINE="--vogl_tracefile pa.bin"
LD_PRELOAD=$HOME/Projects/vogl_chroot/vogl_build/libvogltrace64.so
$HOME/Projects/pa/main/image/linux/PA/PA --hacks --username=jorgen
--software-ui --devmode 2>&1 | tee /tmp/log

$HOME/Projects/vogl_chroot/vogl_build/vogl64 play pa.bin 2>&1 | tee
/tmp/log-play

The contents of /tmp/log and /tmp/log-play are here:

https://gist.github.com/jorgenpt/a39261e107c157f98b2e

You should be able to reproduce this with the Steam version of PA. :-)

Oh, and in addition, the game uses CoherentUI (which spawns a number
of subprocesses), but --software-ui should disable the OpenGL rendering for CoherentUI.

---

Lots of this spew in the logfile:

(vogltrace) Error: vogl_intercept.cpp(5561): vogl_glXSwapBuffersGLFuncProlog():Unable to determine which GL context is associated with the indicated drawable/display! Will not be able to take a screen capture, or record context related information to the trace!

Replay of Xonotic-SDL is in slow motion, while Xonotic-GLX play back at normal speeds

Hello,

the game Xonotic comes with two binaries called xonotic-sdl and xonotic-glx.

When tracing the -sdl client the playback is in slow motion (not in interactive mode). It's not stuttery but plays back at about 20% of normal playback.

==SDL==
The trace: https://www.dropbox.com/s/49s6jkzflbrk90p/vogltrace-sdl_trim.bin
Output of vogltrace64: https://gist.github.com/blackout24/9654151
Output of voglreplay64: https://gist.github.com/blackout24/9654195

==GLX==
The trace: https://www.dropbox.com/sm/create/vogltrace-glx_trim.bin
Output of vogltrace64: https://gist.github.com/blackout24/9654265
Output of voglreplay64: https://gist.github.com/blackout24/9654329

I noticed some vogl warnings about client side arrays and non-whitelisted calls but they appear in both tracer outputs.

For my untrimmed SDL trace voglreplay64 is at index 2000 when the game is still in the menu. In reality it takes about 4 seconds to be in a game in the replay it takes about a minute. The first image of the game appears when voglreplay64 is at index 700, before that the replayer window is black. I trimmed out some gameplay it should be obvious that the SDL trace plays back slow, when looking at the approaching rocket.

It's most noticable in the menu. The game should be in every distros repo if anyone wants to reproduce it.

[Minor Issue] Building with Telemetry On

Attempting to build with:

CC=gcc CXX=g++ cmake ../.. -G"Unix Makefiles" -DUSE_TELEMETRY=On -DBUILD_X64=On -DCMAKE_BUILD_TYPE=debug

Fails.

In file included from /home/gking/Programming/C++/vogl/vogl/src/voglcommon/vogl_common.h:52:0,
                 from /home/gking/Programming/C++/vogl/vogl/src/voglcommon/vogl_ctypes.cpp:40:
/home/gking/Programming/C++/vogl/vogl/src/libtelemetry/libtelemetry.h:37:44: fatal error: ../telemetry/include/telemetry.h: No such file or directory
 #include "../telemetry/include/telemetry.h"

I suppose the problem I have, is that using relative paths might not be the best idea.

RFE: GLES info tables

It'd be nice to know how GLES-compatible a program is. An extra histogram for "GLES API Version" and "GLES clean" table from vogl64 info would be nice to have.

Trimming of trace file fails when starting at certain frame

Hi,

when I take this 1.36 GB trace file (https://www.dropbox.com/s/nqo1t9d6xhgj468/trace2.bin)

and trim it to 100 frames starting at frame 600 I get a working trimmed trace file
(https://www.dropbox.com/s/27h0cgoil7gz9wn/trace2_trim.bin)

Command that was used:
$ voglreplay64 trace2.bin --trim_file trace2_trim.bin --trim_len 100 --trim_frame 600

When I want to trim starting at frame 700 for the same trace file the process fails.

https://gist.github.com/blackout24/9617881#file-gistfile1-txt

I'll see if I can generate a backtace.

Invalid Enum in libvogltrace

GL_DEBUG: GL_INVALID_ENUM in glIsEnabled(GL_VERTEX_ARRAY)
GL_DEBUG: GL_INVALID_ENUM in glIsEnabled(GL_COLOR_ARRAY)
GL_DEBUG: GL_INVALID_ENUM in glIsEnabled(GL_INDEX_ARRAY)
GL_DEBUG: GL_INVALID_ENUM in glIsEnabled(GL_SECONDARY_COLOR_ARRAY)
GL_DEBUG: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
GL_DEBUG: GL_INVALID_ENUM in glIsEnabled(GL_TEXTURE_COORD_ARRAY)
GL_DEBUG: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
GL_DEBUG: GL_INVALID_ENUM in glIsEnabled(GL_TEXTURE_COORD_ARRAY)
GL_DEBUG: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
GL_DEBUG: GL_INVALID_ENUM in glIsEnabled(GL_TEXTURE_COORD_ARRAY)
GL_DEBUG: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
GL_DEBUG: GL_INVALID_ENUM in glIsEnabled(GL_TEXTURE_COORD_ARRAY)
GL_DEBUG: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
GL_DEBUG: GL_INVALID_ENUM in glIsEnabled(GL_TEXTURE_COORD_ARRAY)
GL_DEBUG: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
GL_DEBUG: GL_INVALID_ENUM in glIsEnabled(GL_TEXTURE_COORD_ARRAY)
GL_DEBUG: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
GL_DEBUG: GL_INVALID_ENUM in glIsEnabled(GL_TEXTURE_COORD_ARRAY)
GL_DEBUG: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
GL_DEBUG: GL_INVALID_ENUM in glIsEnabled(GL_TEXTURE_COORD_ARRAY)
GL_DEBUG: GL_INVALID_ENUM in glIsEnabled(GL_FOG_COORDINATE_ARRAY)
GL_DEBUG: GL_INVALID_ENUM in glIsEnabled(GL_NORMAL_ARRAY)
GL_DEBUG: GL_INVALID_ENUM in glIsEnabled(GL_EDGE_FLAG_ARRAY)
GL_DEBUG: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
(vogltrace) Error: vogl_context::peek_and_drop_gl_error (1549): GL error GL_INVALID_ENUM occurred internally while libvogltrace was making GL calls. This GL
error will not be seen by the client app (THIS SHOULD NOT HAPPEN)

I'm using mesa git with 3.1 core profile, maybe mesa is more strict about this? Looking at the specs these values are indeed not allowed for glIsEnabled.

I dont know what the invalid operation is about. In the app i want to trace i use 1 unsupported extension (KHR_debug), could this be a problem?