[sldev] Any OpenGL expert could comment on VWR-5077?

[Carsten Juttner]

Mike Monkowski wrote:
> It appears that the crash was caused by calls to glClear and 
> SwapBuffers.  I have two instances of each.  I know basically what 
> these functions are supposed to do, but I wonder if anyone familiar 
> with OpenGL could tell me where to look to find the root cause of the 
> problem.
>
> Note that the viewer does not crash every time, and in fact, I haven't 
> figured out how to reproducably get it to crash.  So most of the time, 
> it works.  And apparently with other vendor's graphics cards, it 
> always works.  I'm guessing that it's a problem with threads stomping 
> on each other.  It may be threads within the OpenGL driver, though.
>
> So my specific questions are:  Where do glClear and SwapBuffers look 
> to find their parameters for clearing and swapping?  Are OpenGL 
> functions being called from more than one thread in SecondLife?  Has 
> anyone seen anything like this before?


GL is basically a huge state machine, a value you set at a certain time 
may influence another call several frames later which may bite you hard 
if you forget to e.g. reset some flag and wonder why suddenly nothing is 
drawn anymore.

You might want to take a look at GLIntercept 
(http://glintercept.nutty.org) which is a tool that uses a stub 
opengl-library to delegate the actual GL calls and enables you to log a 
lot of useful information. I have used it in the past to track down some 
really nasty state bugs, it is a great tool and also open source.

As for your questions, you really don't know what is happening when 
glClear of SwapBuffers is called. Especially during SwapBuffers the 
driver may work through a lot of GL commands you called in the past and 
which have been queued to e.g. speed them up (by combining actions).

To allow all kind of performance optimizations, GL does not guarantee 
that a command is executed when you call it. There is a way to trigger 
this (glFinish) but you usually don't need to use this.

What SwapBuffers is *supposed* to do is to exchange the front and back 
buffer (you usually work double buffered to avoid tearing effects). But 
it might do much more which is really up to the specific driver 
implementation.

Regarding threads, for GL API users it is highly recommended not to use 
GL calls from more than one thread (though it is possible but with some 
limitations) and from what I saw so far, the SL viewer seems to follow 
that recommendation.

I am not surprised Intel does not want to support a specific application 
but from my experience it is usually very helpful to present a small 
reproducer application. Of course for that to work you need a way to 
actually reproduce the problem. :-/

Looking at the stack trace it might be helpful to know that opengl.dll 
is really only a microsoft library which calls the "installable client 
driver"-library from the vendor to do the real work. You can see the ICD 
name part in the iglicd.dll name.

Debugging sporadic crashes as you describe them can be a daunting task, 
especially if you don't even know what the opengl driver is doing 
internally. It might simply be some specific state setup that is handled 
well by other drivers and which causes the intel implementation to fall 
over.

Regards,
Carsten