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

[Kent Quirk (Q Linden)]

Mike Monkowski wrote:
> I'm looking into crashes with Intel graphics chipsets.  I've posted 
> four sets of diagnostics at 
> http://jira.secondlife.com/browse/VWR-5077  In all cases, it crashed 
> the display driver and left the OpenGL driver spinning in loops.
>
> Intel support says they do not support Second Life even though they 
> have a forum dedicated to Second Life, and in the forum they say to 
> contact support if you have any problems.  Go figure.
>
> 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?
>


Mike:

In all of the diagnostics posted in VWR-5077, the crash was inside the 
graphics driver.

This is pretty common in graphics and games, and is almost always an 
indication of a problem with the driver. In particular, SwapBuffers may 
be doing all sorts of things prior to actually swapping the buffer, 
because it has to flush the graphics pipeline before it can swap. 
Similarly with glClear. So these are two of many examples where the 
crash is likely happening far from the code that causes the crash.

I'm not saying it's not worth trying to figure out what might be driving 
the bug, but sadly, such bugs are often a "whack-a-mole" type of problem 
-- you push it down in one place by  and cause a problem somewhere else. 
Generally, when building games and graphics applications, you fall back 
on a "majority rules" model -- if most drivers and cards on the market 
render the graphics correctly, you assume you've done it right. From 
time to time, it's the minority that's "correct" and the majority just 
happen to work...but that's rare.

Chances are good that the viewer is not doing anything "wrong", it's 
just that the driver can't handle something we're doing. You may be able 
to find something to change to prevent the crash...but the change may 
affect rendering in some other situation. There's no problem with 
threads -- we don't use multiple threads in the viewer (with the 
possible exception of audio, which I don't know anything about).

    Q