we’ve noticed a serious issue with the OpenGL drivers in quadbuffered stereo mode. Our setup is a powerwall with 8k resolution, configured at a mosaic mode of 2x2 4k displays/projectors (the displays are for our test setup, the powerwall uses projectors and thus edge blending, so the resolution is not quite 8k there). The whole thing is operated by one machine with four Quadro-synced M6000. Now the issue is serious instability of the system. We recently noticed that every time we initialize a stereo window and close it afterwards, according to SystInternals ProcExp we lose 300MB of video RAM, which do not seem to get released. As a result, after something like 10 runs, we can no longer start applications due to a gl-driver Error-Messagebox popping up (something about Error #3, #5 and sometimes #8) and we have to reboot our system. The Applications are quit properly, there is no crash. Overall, the whole system gets slower, less reactive and very unstable in general, I’m pretty sure, that issue’s related. This only happens in stereo mode, everything runs smoothly in mono. We use Windows 8.1 64 Bit, with latest versions of SDL and freeglut for windowing and also the latest version of glew. We tried several driver version, currently we’re running 348.27. We also tried the 35X branches but downgraded again, as recommended by Nvidia, since it does not (properly?) support Quadro Sync yet.
At  you can find a small test application (msvs12) which enables to reproduce the issue quite easily. All I do is initializing a stereo window and clear the back buffers in the render loop. You can also try mono/windowed/destop-fullscreen by setting the respective flags and will find the issue is not present in mono but in stereo, in windowed, true fullscreen, and windowed fullscreen mode. I tried this here on my desktop machine with a Quadro 4000 and get the same behaviour, even though the leak is considerably smaller and, weirdly, quite varying (between 25 and 125MB each time, at 1920x1200), while in our powerwall setup it is constant at about 300MB.
Would be great to get some feedback also about possible traps or misusage on our side. There is also another stereo problem, we’re still having with an application rendering huge chunks of GL_POINTS, I already described the issue at , I’m not sure if this is related, but maybe it is.