On Monday 13 August 2007, Nicholas S-A wrote: > On Aug 6, 2007, at 8:49 AM, Timothy Normand Miller wrote: > > On 8/6/07, Thomas Kumlehn <[EMAIL PROTECTED]> wrote: > >> Could > >> anyone estimate the resources that would be needed to have a pixel > >> output stage that does not directly go to the 2 DVI chips but first > >> uses both screens pixel values to calculate front/back pixels and send > >> those to the LCDs ? > > > > I'm not sure I understand the full extent of it, but it doesn't sound > > too hard. > > Hmm... this looks interesting. I think, but am not sure, that we could > simply use > the OpenGL Z-buffer to figure out the "3D" effect and we should be able > to generate > the 3D image -- or we just suggesting pure display of two framebuffers > (sent from the > CPU, either software OpenGL or some other video card) that are mixed > on the two DVI outs?
The latter. I'm fairly sure you have to render two separate images, then combine to two framebuffer images to get the stereo composite. The z buffer doesn't help you recover pixels that are obscured on one eye and visible in the other. Rendering the two images is something that is IMHO entirely a software driver problem. Obviously it's a trivially parallel task so if you have two sets of hardware you can do one image on each. There are probably also driver tricks you can play to reduce state switching overhead on a single card. Combining the images to get the two monitor outputs is a relatively simple 2D operation. It's probably desirable to do this on the card to avoid having to blit the framebuffer contents to system memory and back. Paul _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
