GLSL Volume Raycasting Fragment Shader stalls


I have a kind of strange problem with a little fragment shader based volume raycaster. From time to time it happens that the shader execution stalls, causing the application to hang a short time. What’s even worse is that the stalling quite often exceeds 2 seconds so Windows kills the display driver and thereby causing the application to crash.
To track the problem down I stripped the application of any unnecessary parts but without luck. Only thing I noticed is that the origin might be a texture3d call within a loop in the fragment shader (to get the voxel data along the ray).
I took a look around for any known problems regarding 3d textures and GLSL but, again, without any luck.

Since it would take a while to explain the whole app/shader, here is a link to source and binaries of the sample application in case anybody feels like having a look:
[see below for link] (it’s trafficshared, so you don’t have to wait or anything)
The stalling happens on almost all systems, although fast and very slow ones mostly don’t reach the 2 seconds. But a lag is still noticable (especially with Fraps). To reproduce, just hold down the left mouse button and rotate around fast. On my notebook it takes about 15 to 20 seconds to crash.
(x is for quitting)

Any hint regarding a probable cause or even remotely connected known problem would be highly appreciated since I just can’t find anything and commercial raycasters working the same way don’t seem to have that problem. :frowning:

P.S.: Hope I didn’t forget any vital information…

edit: I wouldn’t advise to test the sample application under Windows XP since I didn’t test it and it might crash the whole system instead of the driver. Afaik Vista is the first Windows OS with a usermode driver that can be restarted on the fly.

Me again. Another symptom appeared, though I’m not quite sure what to make of it.

First of all, here is a better sample application where no user interaction is needed to produce the stall:

I use a timer to rotate the box in this sample.
Rotation is as usual:

Gl.glRotatef(cubeRotationAroundX, 1, 0, 0);
Gl.glRotatef(cubeRotationAroundY, 0, 1, 0);

The angles to rotate around are randomly determined in the timer tick. What I noticed during some extensive testing is, that the stalling occurs dependent on the rotation:

// no crash, no stalling
int rot = _rnd.Next(10);
cubeRotationAroundY += rot;
cubeRotationAroundX -= rot;
// no crash, no stalling
cubeRotationAroundY += _rnd.Next(10);
//cubeRotationAroundX -= _rnd.Next(10);
// no crash, no stalling
//cubeRotationAroundY += _rnd.Next(10);
cubeRotationAroundX -= _rnd.Next(10);
// crash
cubeRotationAroundY += _rnd.Next(10);
cubeRotationAroundX -= _rnd.Next(10);

// crash (seems to happen earlier than above)
if(_rnd.NextDouble() < 0.5)
      cubeRotationAroundY += _rnd.Next(10);
      cubeRotationAroundX -= _rnd.Next(10);

(Crash simply means that the stalling was long enough to have the display driver killed by Windows)
So if both angles are equal or at least one of them is 0, everything is fine…
Hopefully someone can make something of that.


i’ll get the ball rolling then.
let’s start with the brand of graphics card.
eventually, many posts on, we’ll probably get to the driver version.

As a start, I’d like to quote myself: “The stalling happens on almost all systems, although fast and very slow ones mostly don’t reach the 2 seconds.”

In detail: Brands are nVidia and ATI. It’s been tested on a 4000 series ATI card, a Geforce GTX 260M, 8800GT and Quadro FX 500M series. Don’t know all the driver versions but they cover a wide range from newest to a little rusty. OS: XP, Vista and W7 (32 and 64 bit)

edit: And a bunch of other cards I can’t remember (some NVS and slower ATIs I think). Anything I could get my hands on.

Before you go too far in raycasting, do note that the GLSL memory model forbids recursion.