podvilla

I was recently working on implementing an OpenGL layer to our rendering engine and was using GLIntercept to find out what was going on “under the bonnet”.  The first problem I encountered was that some of my asserts for GL_NO_ERROR == glGetError() were firing, in seemingly benign locations. After a whole lot of Google detective work, I found what I believe to be the conclusive diagnosis for this issue. It seems to be an artefact of a particular setup combination – NVidia drivers (I have a GeForce 8400M GT in a Dell Vostro laptop) and Vista.

The post below describes how the NVidia driver is unusual in that it fires off another thread which calls wglGetPixelFormat whenever SwapBuffers is called, and if you are running GLIntercept, this multithreaded access causes a false positive to occur. I think the reason my asserts were firing is that the gl error state persisted beyond the SwapBuffers and fired whenever the next gl command was issued.

Anyway, I hope this find is of use to someone, it’s taken me a couple of days to work it out!

I found my rendering problem and have posted another message requesting help with that (dirtying color arrays when vbo are used). I also tracked down the problem in GLIntercept. I have hacked up a fix for that but a proper one will require a far more comprehensive look at the architecture of GLIntercept.

The problem stems from the fact that the underlying driver is making calls back into OpenGL on another thread when some OpenGL functions are called. and that GLIntercept intercepts calls to glGetError and returns a cached error value in some circumstances.

This leads to the following.

1. Main thread calls SwapBuffers (windows GDI function) which eventually calls wglSwapBuffers which is intercepted by GLIntercept.
2. GLIntercept end up calling the real glGetError to check the result of the wglSwapBuffers.
3. The nvidia drivers implementation of glGetError for some reason tells (or maybe creates) another thread to do some work and waits for it to complete.
4. The other thread calls wglGetPixelFormat which is intercepted by GLIntercept, which again calls the real glGetError, luckily this does not seem to bother with another OpenGL call, however the cached error code is now messed up.
5. The worker thread releases the main thread which returns
6. The main thread calls glGetError (I have the OSG check every frame option set) and gets a bad cached value from GLIntercept.

My fix is very hacky and just stops GLintercept calling glGetError if it is already in the process of doing so. This gets rid of most of the spurious errors.

I dont plan to go much further. GLIntercept also crashes on program exit it the runtime heap checks. But the logs seem OK. Let moe know if you want the modified code.

I’m in the middle of porting some game engine code to a GCC based build system, and got potholed badly. So far, this code has only ever been compiled by MSVC, and the loving touch of GCC’s standards compliance has been most revealing.

Consider this bit of template code (which compiles fine on MSVC):

    template<class RESOURCE>
    struct ResourceArray : public std::vector<RESOURCE>
    {
        std::vector<RESOURCE>::iterator Find(RESOURCE pResource)
        {
            std::vector<RESOURCE>::iterator it;
            for (it=begin(); it!=end(); ++it)
                if ((*it) == pResource)
                    return it;
            return it;
        }
    };

The first attempt to get GCC to compile this generates some very misleading errors, and my initial interpretation was there was either a namespace or a precompiled header issue.

../Code/include/GeResource.h(56): error: expected ';' before 'Find'
../Code/include/GeResource.h(64): error: expected `;' before '}' token

Having determined that it wasn’t namespace or pch related, I looked at trying to reduce the code and isolate the problem. The first step was to introduce some typedefines for those iterators, something I’ve incedentally started to do by habit anyway (all that std::vector<TYPE>::iterator stuff gets a bit verbose doesn’t it?).

    template<class RESOURCE>
    struct ResourceArray : public std::vector<RESOURCE>
    {
        typedef std::vector<RESOURCE>::iterator    ResourceIterator;

        ResourceIterator Find(RESOURCE pResource)
        {
            ResourceIterator it;
            for (it=begin(); it!=end(); ++it)
                if ((*it) == pResource)
                    return it;
            return it;
        }
    };

This still didn’t compile, but produced much more useful error messages, in particular an explicit fault with the iterator declaration.

../Code/include/GeResource.h(56): warning: ISO C++ forbids declaration of 'iterator' with no type
../Code/include/GeResource.h(56): error: cannot declare member 'std::vector<_Ty, std::allocator<_Elem> >::iterator' within 'GeLib::ResourceArray<RESOURCE>'
../Code/include/GeResource.h(56): error: expected ';' before 'ResourceIterator'
../Code/include/GeResource.h(58): error: 'ResourceIterator' does not name a type

Doing a bit of hunting on this error message was most fruitful. Indeed GCC is pointing out that my code is ambiguous and does not meet the recent C++ standards. Declaring types based on template parameters needs to done in an explicit fashion using the typename keyword.

A quick refactor of the code, using the typename specification as well as a bit of explicit scoping, gives us the clean compile we desire!

    template<class RESOURCE>
    struct ResourceArray : public std::vector<RESOURCE>
    {
        typedef             std::vector<RESOURCE>              ResourceVector;
        typedef typename    std::vector<RESOURCE>::iterator    ResourceIterator;

        ResourceIterator Find(RESOURCE pResource)
        {
            ResourceIterator it;
            for (it=ResourceVector::begin(); it!=ResourceVector::end(); ++it)
                if ((*it) == pResource)
                    return it;
            return it;
        }
    };