From: John Stone (johns_at_ks.uiuc.edu)
Date: Fri Jan 24 2003 - 14:01:55 CST

Hi Warren,
  I've written a long email to the NVidia guys about this and a few other
problems I've been seeing with their drivers, and the lack of documentation
regarding the limitations of their hardware and drivers, I'm hoping that
we can work together to improve this situation, as I think its silly to
have Quadro-specific hacks unless its absolutely necessary. The workaround
you're using would definitely work in VMD.

I think NVidia should be doing this inside their driver. I will continue
protest the idea that this sort of hack should be necessary in application
code until someone proves to me that the NVidia hardware/software is
incapable of implementing stereo correctly for some insurmountable reason.
Your workaround is logical, but if I start adding lots of card-specific
hacks to VMD now, I would soon have 20,000 lines of OpenGL hacks to
workaround the deficiencies of individual cards, all of which are
inherently transient in nature. I already feel guilty if I spend more
than a minimal amount of time adding support for vendor-specific
OpenGL extensions that will be irrelevant in 3 years.
(i.e. the current Quadros may be broken, but is it really worth writing
 special hacks to fix a card that won't matter in another year or two??
 If enough VMD users say "yes", then I can justify it, but since this
 problem would affect ANY normal stereo-capable OpenGL app, I think the
 onus is on NVidia to try to fix it first.)

I dislike the idea of taking any performance hit, but your solution is
the most reasonable thing I've heard so far, though I hate the idea
of taking a 50% speed hit by default. Hopefully NVidia will see the
light and implement this workaround in their own drivers, or fix them
entirely. Without more information I have no idea why they have a software
fallback here in the first place. Hopefully we'll get more info on this.

Regarding your comment about not having the hardware, this is the same
issue for me. One lab can't possibly have 200 test machines with every
video board. If NVidia documented their drivers and hardware better,
then software developers like us could make our apps auto-detect the cards
and use sane defaults depending on what their docs say.

If you hear anything else on this, let us know.

Thanks!
  John Stone
  vmd_at_ks.uiuc.edu

On Fri, Jan 24, 2003 at 11:44:14AM -0800, DeLano, Warren wrote:
> PyMOL is similarly tweaked by nVidia's stereo support. The only trivial solution I've found is to leave PyMOL in stereo mode and render both the left and right buffers, even when you want a mono image. You just set the stereo angle and stereo separation to zero -- I bet the same trivial workaround could be applied to VMD.
>
> The performance hit is still 50%, but that's a whole lot better than the 99% percent hit you get from the software renderer. I don't have access to this hardware myself, so I haven't figured out a more efficient workaround.
>
> Cheers,
> Warren
>
>
>
> --
> mailto:warren_at_sunesis.com
> Warren L. DeLano, Ph.D.
> Informatics Manager
> Sunesis Pharmaceuticals, Inc.
> 341 Oyster Point Blvd.
> S. San Francisco, CA 94080
> (650)-266-3606 FAX:(650)-266-3501
>
>
>
> > -----Original Message-----
> > From: John Stone [mailto:johns_at_ks.uiuc.edu]
> > Sent: Friday, January 24, 2003 8:20 AM
> > To: Michael Redmond
> > Cc: vmd-l_at_ks.uiuc.edu
> > Subject: Re: Stereo mode on NVidia/Win2000
> >
> >
> >
> > Dear Michael,
> > The response you got is accurate. However, this is normal
> > practice, and
> > there are no such performance issues on the many many other
> > cards and drivers
> > out there. I could produce a list of around 30 other video
> > boards that
> > don't have this problem. I can only assume that the NVidia
> > drivers you're
> > using "punt" in this particular case and fall back to a
> > software rendering
> > operation of some kind?
> >
> > Since they (NVidia) don't currently mention this deficiency in their
> > latest 4191 driver README, I think that they should begin by
> > documenting
> > this problem, along with suggested workarounds. I know of
> > various other
> > NVidia driver bugs which are also not documented, though I
> > have reported
> > them previously.
> >
> > If they have a suggestion that doesn't involve creating and destroying
> > windows on the fly, I'm willing to consider it. I still feel
> > that this
> > is a deficiency in their OpenGL implementation since no other platform
> > I'm aware of has this problem. Page 436 of the OpenGL 1.2
> > programming guide
> > specifically covers the expected behavior when the
> > drawbuffers are set to
> > GL_FRONT and GL_BACK when running in a stereoscopic visual. Clearly
> > the intent is that using GL_FRONT and GL_BACK allows one to draw
> > monoscopic images regardless of the use of a
> > stereoscopic-capable OpenGL
> > context. If they disagree, I'd like to know what their rationale is.
> >
> > Anyway, if they have any suggestions, let me know. I'm
> > willing to build
> > you a special version of VMD to see if it cures the problems
> > you're having.
> > I'd still like to see NVidia get serious about documenting
> > the limitations
> > of their drivers, both on Windows and on Linux. Right now
> > its a bit like
> > walking into a mine field blindfolded. The situation would be greatly
> > improved if they provided the sort of documentation with their drivers
> > that vendors like Sun, SGI, and HP have historically given out.
> > Here's a good example of what they should be shipping with their
> > driver software:
> >
> > http://wwws.sun.com/software/graphics/OpenGL/1.2.3/SolImpPerfG
> > uide1.2.3.pdf
> >
> > If you read Sun's docs, you'll see that they specifically address the
> > OpenGL operations which can cause software rasterization to occur on
> > the various graphics boards they sell. Since NVidia doesn't
> > provide any
> > docs of this sort with their drivers, we're left wondering why their
> > cards behave badly in various circumstances, not knowing if its a bug
> > in their driver, or simply a limitation of the hardware. Many people
> > would love to see NVidia step up and produce a document of
> > this quality
> > to ship with their Windows and Linux drivers. Presently,
> > they have lots
> > of example apps on their web site, but they don't address many of the
> > issues like the stereo performance you're having, nor similar
> > issues with
> > enabling multisample antialiasing on high-res windows, etc.
> >
> > Anyway, if you want to pass this along to them, that would be helpful.
> > If they have any suggestions regarding workarounds for the
> > stereo performance
> > problem you're having, I'm willing to see if we can implement
> > them for you.
> >
> > John
> >
> > On Fri, Jan 24, 2003 at 09:29:55AM -0600, Michael Redmond wrote:
> > > We have been running VMD with Quadro cards (550XGL and
> > 900XGL) under
> > > Windows 2000. We use quad-buffered OpenGL stereo support of
> > the Detonator
> > > drivers with shutter glasses (all kinds) or in Clone mode
> > (with a Geowall
> > > stereo projection system). It basically works, but we have
> > a performance
> > > problem when we start up VMD in default, mono mode. Image
> > manipulation is
> > > horrendously slow! However, as soon as we switch to
> > Crystaleyes stereo,
> > > performance is great (maybe 30X speedup). Other
> > applications have similar
> > > problems in both Windows and Linux.
> > >
> > > I have been working with PNY and NVidia folks to address
> > this and other
> > > Quadro issues. I got a note back with the following query:
> > >
> > > ---
> > > The performance problem I would guarantee is because they
> > are using a
> > > stereo pixel format in mono-mode (i.e. selecting a stereo
> > pixel format
> > > and then setting the buffer to back/front not back_left, back_right,
> > > front_left, front_right). This will cause the driver to drop to a
> > > software path.
> > >
> > > This may in turn be causing the issues with the switching etc.
> > >
> > > Do they have control over the application source code?
> > >
> > > Could they confirm if they are using mono-mode or not?
> > >
> > > ___
> > >
> > > At this point, I haven't looked at the source. I am hoping
> > I can get a
> > > quick answer here without having to try deciphering source.
> > >
> > > If this is the problem, is there a way to address it in
> > future versions of
> > > VMD?
> > >
> > > Thanks
> > > Mike Redmond
> > > Associate Director, eMedia Center
> > > UW-Madison
> >
> > --
> > NIH Resource for Macromolecular Modeling and Bioinformatics
> > Beckman Institute for Advanced Science and Technology
> > University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> > Email: johns_at_ks.uiuc.edu Phone: 217-244-3349
> >
> > WWW: http://www.ks.uiuc.edu/~johns/ Fax: 217-244-6078
> >

-- 
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email: johns_at_ks.uiuc.edu                 Phone: 217-244-3349              
  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078