VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Fri Jan 24 2003 - 10:20:10 CST

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/SolImpPerfGuide1.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