Stereo Reverse In Quad Buffer Problem


Does anyone know the reason why I experience stereo reverse on Quadro FX3000 (with DIN connector) when texture memory exceeds?
When the textures are well within the texture memory limit, the stereo is fine but when it exceeds, the left buffer becomes the right and vice versa.
Is there any solution to this?

Cheers and thanks in advance,

Errr …
Is there any one who can answer this question or did I phrase it wrongly?


Sounds like a driver bug with the glasses vs buffers going out of phase. You need to provide more info on the type of stereo and setup and perhaps also try different driver versions & stereo options if available. Off hand I’d say you need to contact the manufacturer(s). Other factors like is it consistent or does it keep flipping when you overload are important. Some weaker techniques have a dependency on frame rate. Are you using full quad buffer stereo with native graphics hardware support and a synchronization connector from the graphics card straight to the glasses (or related hardware) or is something a bit less robust being used?

NVidia does not have hardware-based stereo page-flipping support, so the apparent reversal is probably due to loss of stereo sync in their software-emulated mechanism. FWIW, ATI’s Radeon stereo support is hardware-based.

Thanks for the replies.
I guessed that explains why the stereo goes out of sync when texture memory exceeds, probably lack of resources that caused the pointers to reverse. Guess the only way is to ensure texture memory does not exceed.


No, lack of memory resources don’t cause “pointers to reverse”. Some memory paging in the driver may cause it to miss a time critical vertical retrace sync or perhaps even sends it out to lunch for several frames throwing off any attempt to reconstruct which eye a particular refresh field represents.

With software synchronization schemes the systems performance is critical and shutter sync has some loose real-time requirements. Unfortunately the operating system and drivers can’t guarantee diddly and you are suffering the consequences when you overload the system with texture paging requests.

It’s a great example of why some discerning customers must buy high end ‘workstation’ class cards (and pay thousands of dollars extra) for a few seemingly inconsequential (even archaic) features that would cost a few cents to provide on every graphics card, simply because there is no broad demand for them at the low end, despite amazing developments there in other features there.

… err or it would be a great example if ATI consumer products didn’t solve the problem in hardware :-/.

If it’s any use to you, I’ve never, repeat, never experienced this problem with quadro cards.
I work with them in stereo day in day out, with huge data sets flying around.
I don’t know whether the software-emulation claim is true or not - I suspect it’s not true, as to do that synchronisation in software would be…impossible? Swap-buffer locks maybe, but not vsync locks which is needed for shutter glasses.

FWIW - The issue here is not the synch to video refresh but the sync to left and right fields in an already sync’d system (in this case). When you’re already locked to the video refresh (and your glasses have to be, obviously, it is trivial and a given that vsync clock is getting to the glasses), you may have a time window the length of a full frame in which to sync the necessary updates the depending on the implementation details (which we don’t know, could be queuing a buffer copy on a vsync or ‘page flipping’ the video fetch (obviously not for windowed non mux)), other stuff could get stuffed too like what gets sent to the glasses but since I don’t know it’s all speculation. It may be very robust under most circumstances, but can fail under load.

We don’t have enough technical details so yup, take my guesswork with a pinch of salt.