8/31/2011

about using GL_ARB_get_program_binary

While trying to experiment with the GL_ARB_get_program_binary extension, I found various sample code that seemed a little flowed, while the 'official' sample code in the spec is fine.

To sum it up, when using glGetProgramBinary to fetch the binary representation of the shader (program is GL wording), OpenGL provides an 'opaque' binaryFormat value that is meant to be kept with the binary data. This value is needed when calling glProgramBinary to construct a shader from the binary data.

For a basic usage, there is no need to enumerate the available binary formats using a glGet with GL_PROGRAM_BINARY_FORMATS.

To retrieve the shader binary, one must call :

GLenum binaryFormat = 0;
GLsizei binaryLength = 0;
glGetProgramBinary( program, BUFFER_SIZE, &binaryLength, &binaryFormat, buffer );

To reconstruct a shader with the binary data :

glProgramBinary( program, binaryFormat, buffer, binaryLength );

One more thing is that, in order to be able to get the binary representation, you need to hint the driver about it ; and this must be done before linking the shader. This is done by calling :

/* must come before glLinkProgram or glProgramBinary */
glProgramParameteri( program, GL_PROGRAM_BINARY_RETRIEVABLE_HINT, GL_TRUE );

So far so good, it seems to work fine on latest drivers by NVidia or AMD, while it seems that the performance gain is more important on AMD - my preliminary measures give me strange results, so I got to double check them.

7/19/2011

Discardable debug message logging in python

After a short discussion about handling of diagnostics messages in python, and the cost of calling 'do nothing' functions in python, I just had an idea.

The point is to be able to (quite) brainlessly insert calls to some debug logging function through python scripts.

Alas, these calls have a cost, which we are willing to pay for a 'debug' run, but not a 'release' run, where things should go fast (or python-fast to be relative).

One first option would be to have a 'do-nothing' function replacing the logging function in 'release' runs :
if __debug__:
def DBGLOG(message):
print "[D] " + message
else:
def DBGLOG(message):
pass # do nothing
...
DBGLOG("some fancy message")

This works fine, but as CPython does not have any fancy dead code optimization combined with function inlining, it will always evaluate the arguments to the function before doing nothing. Hence, the following call will always cost some time :
DBGLOG("some message with costy parameter : '%s'" + str( [x for x in SOME_LIST ] ))

To prevent evaluating the arguments, we could use a good old if, but I don't like the thought of cluttering code with if statements...
if __debug__:
DBGLOG("some message with costy parameter : '%s'" + str( [x for x in SOME_LIST ] ))
The only form of conditional compilation I could find, in python, is related to the assert statement ; which is only evaluated if the interpreter constant __debug__ is true. We can use this at our advantage here :
assert DBGLOG("some message with costy parameter : '%s'" + str( [x for x in SOME_LIST ] ))
In this case, the parameters are not evaluated in 'release' runs (interpreter running with '-O' option).

Some quick and dirty benchmark comes below :



With the following results, on my machine :

'pass' time: 3.934145msec

'empty logging function' time: 247.512817msec

'if __debug__' time: 3.726006msec

'if ENABLE_DEBUG_MESSAGES' time: 6.114006msec

'assert logging function' time: 3.714085msec