From: John Stone (johns_at_ks.uiuc.edu)
Date: Tue Jan 04 2005 - 18:22:52 CST

Sabuj,
  Yeah, just make sure you include the text from my emails as well.
I'll be filing a similar bug report for the NVidia Quadro FX 3000 card
that I just tested earlier this week, which gave the same problem.
It's a fortunate coincidence that you ran into this the same week I
was testing the FX 3000, as it would have been harder to guess your
problem otherwise. I'm surprised they haven't long-since fixed this
bug. I've found some other bugs lately too, so I guess it's just how
things go. If we both report the bug, with two different boards in
two different systems, and multiple driver versions, but with the
one version you've found that actually works _correctly_, I think that
will help them track down the problem and hopefully they'll fix it finally.
I think I first reported this problem to NVidia way back in 2002, so
I know they've known about it for a while, though they've obviously
forgotten since then.

  John Stone
  vmd_at_ks.uiuc.edu

On Tue, Jan 04, 2005 at 06:17:30PM -0600, Sabuj Pattanayek wrote:
> In short, I think you may be correct that there is an opengl stereo bug
> in some drivers older than and probably everything newer than 5336.
>
> To make sure I just reinstalled the v1.0.5336 drivers again and started
> vmd 1.8.2 with setenv VMDPREFERSTEREO 1, loaded up 1tf7.pdb. The speed
> is fine in regular lines, dynamic bonds, or msms mode at 1600x1200 full
> screen in both regular display mode and when I set it to crystaleyes mode.
>
> The stereo works fine in crystaleyes mode with my nuvision 60gx emitter
> and glasses.
>
> I'm not exactly sure what to send to linux-bugs_at_nvidia.com. I really
> know nothing about opengl internals or api calls. Would a summary of
> everything you told me and the steps I took to reproduce them suffice?
>
>
> John Stone wrote:
> >Sabuj,
> > Did your older v1.0.5336 drivers exhibit the stereo performance problem,
> >did they even actually implement stereo? If you don't experience the
> >problem
> >and are able to use stereo with v1.0.5336, then we should send a bug report
> >to NVidia and try to get them to fix the new drivers since it would seem
> >from what you're saying that they did have them working correctly in
> >that previous driver version. If you 1.0.5336 doesn't support stereo,
> >then I'd suggest using the new driver and set the environment variable
> >the way you need until I come up with a workaround or NVidia fixes the
> >new drivers. Either way, we should complain to NVidia again, since no
> >other graphics board I've ever encountered exhibits this type of
> >performance loss when rendering in a non-stereo manner to a stereo visual.
> >NVidia's bug email address is linux-bugs_at_nvidia.com
> >
> > John Stone
> > vmd_at_ks.uiuc.edu
> >
> >On Tue, Jan 04, 2005 at 05:28:46PM -0600, Sabuj Pattanayek wrote:
> >
> >>Yup, running vmd 1.8.2 and hardware stereo is enabled in XF86Config
> >>(Option "Stereo" "3"). What you said worked, that is the speed is normal
> >>with the newer drivers and VMDPREFERSTEREO off and that the speed
> >>becomes normal if VMDPREFERSTEREO is on and hardware stereo is enabled
> >>(crystaleyes mode).
> >>
> >>So would you suggest that I use the newer drivers where I have to turn
> >>the variable on or off depending on whether I want stereo or v1.0.5336
> >>where it doesn't seem to matter? I mean are there any performance or
> >>features gained as far as visuals are concerned with the newer drivers
> >>or does it not really make a difference in VMD?
> >>
> >>Thanks for your help!
> >>
> >>John Stone wrote:
> >>
> >>>Sabuj,
> >>>I assume you're running VMD 1.8.2? If not, let me know which version
> >>>of VMD you're using and I can give more suggestions.
> >>>
> >>>I know that NVidia made a lot of changes that relate to the
> >>>implementation
> >>>of stereoscopic rendering on the Quadro cards. Even now with the most
> >>>recent
> >>>drivers, they have a particularly egregious performance issue that
> >>>affects
> >>>stereo rendering. If you have stereo enabled in your NVidia driver, and
> >>>you're running VMD with the "VMDPREFERSTEREO" variable set, but you
> >>>_don't_ have VMD displaying in stereo, there's a HUGE performance loss
> >>>caused
> >>>by the way their OpenGL driver implements glDrawBuffer(GL_BACK) when
> >>>running
> >>>in a stereoscopic visual. No other cards/drivers I've ever seen have
> >>>this
> >>>problem, and it's a huge speed hit. My understanding is that NVidia
> >>>implements
> >>>glDrawBuffer(GL_BACK) with a software-based pixel copy when you're
> >>>running
> >>>in a stereo mode but not rendering in stereo. When one calls
> >>>glDrawBuffer(GL_BACK_LEFT) or glDrawBuffer(GL_BACK_RIGHT) the problem
> >>>goes
> >>>away and speed is normal (i.e. when you have the stereo mode in VMD
> >>>set to CrystalEyes).
> >>>
> >>>All said however, this only affects you if you have the board running in
> >>>a stereoscopic mode. Since you didn't say what video mode you're using,
> >>>I'm not even certain any of this applies to you. A lot of people with
> >>>Quadro cards buy them specifically so they can do stereo, so I thought
> >>>I'd mention this particular issue so you're aware of it.
> >>>
> >>>The NVidia X config option for stereo is usually:
> >>>Option "Stereo" "3"
> >>>
> >>>So if you see that in your config files, that may be related to your
> >>>performance problem.
> >>>
> >>>John
> >>>
> >>>On Tue, Jan 04, 2005 at 04:06:39PM -0600, Sabuj Pattanayek wrote:
> >>>
> >>>
> >>>>Hi,
> >>>>
> >>>>Ayone know why I would have terrible graphics performance for some of
> >>>>the newer and older Linux_x86 nvidia drivers except for v1.0.5336 on my
> >>>>quadro 750 xgl card and only for VMD v1.8.2 (not with any other
> >>>>modeling programs e.g. chimera, spdbv, ribbons, turbo, o, etc)?
> >>>>
> >>>>The other driver versions I tested are: 1.0.6229 (latest), 1.0.6111, &
> >>>>1.0.4365 which is "quadro certified" but all of them give really poor
> >>>>performance compared to 1.0.5336 in VMD.
> >>>>
> >>>>These are the settings for all the drivers:
> >>>>
> >>>>glxinfo | grep direct
> >>>>direct rendering: Yes
> >>>>
> >>>>cat /proc/driver/nvidia/agp/status
> >>>>Status: Enabled
> >>>>Driver: NVIDIA
> >>>>AGP Rate: 4x
> >>>>Fast Writes: Enabled
> >>>>SBA: Enabled
> >>>>
> >>>>I also tried switching between agpgart and nvidia's agp for all of the
> >>>>drivers but there is no difference. The system is running under a
> >>>>2.4.28 kernel. I thought it might be related to the issue below so I
> >>>>included the forward.
> >>>>
> >>>>Thanks
> >>>>Sabuj Pattanayek
> >>>>
> >>>>John Stone wrote:
> >>>>
> >>>>
> >>>>>Hi,
> >>>>>Generally speaking, remote rendering will be significantly slower
> >>>>>than local rendering, so you only want to do this when you have no
> >>>>>other choice. This is particularly true for apps that draw a lot of
> >>>>>geometry using immediate mode OpenGL. We've made a large number of
> >>>>>changes in VMD 1.8.3 to make it more remote-display friendly (and
> >>>>>faster
> >>>>>in general..) but even so, you'll still notice a big difference between
> >>>>>local and remote display performance.
> >>>>>
> >>>>>You might also experiment with enabling "Display->Cachemode->On" in
> >>>>>the GUI of VMD 1.8.3b1, this enables a feature which can give a huge
> >>>>>performance boost on remote displays, tiled displays, etc.
> >>>>>For the display of a static molecular structure, the display cachemode
> >>>>>feature
> >>>>>should give you anywhere from a 10x to 50x performance boost over
> >>>>>normal
> >>>>>rendering. Some machines also get a performance benefit for local
> >>>>>rendering when the caching code is enabled, but that's less frequently
> >>>>>the case than
> >>>>>for remote display. Try that out and let us know how it works for you.
> >>>>>
> >>>>>John
> >>>>>
> >>>>>
> >>>>>On Tue, Dec 28, 2004 at 03:39:32PM +0100,
> >>>>>Greipel.Joachim_at_MH-Hannover.DE wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Hi All,
> >>>>>>I am setting up VMD on a DUAL-Opteron machine for rendering on remote
> >>>>>>X-Servers which run under Linux and are equipped with NVIDA Quadro
> >>>>>>Graphics and Hardware Stereo.
> >>>>>>
> >>>>>>The rendering on the remote machines worked (even stereo display with
> >>>>>>crystal eyes) but unfortunately it was very (!) slow. I just
> >>>>>>installed the 1.8.3b1 version and to my surprise the rendering on the
> >>>>>>remote machines is now acceptably fast.
> >>>>>>
> >>>>>>There are slight differences in the startup messages of VMD
> >>>>>>
> >>>>>>1.8.3b1 ("fast rendering")
> >>>>>>
> >>>>>>Info) Email questions and bug reports to vmd_at_ks.uiuc.edu
> >>>>>>Info) Please include this reference in published work using VMD:
> >>>>>>Info) Humphrey, W., Dalke, A. and Schulten, K., `VMD - Visual
> >>>>>>Info) Molecular Dynamics', J. Molec. Graphics 1996, 14.1, 33-38.
> >>>>>>Info) -------------------------------------------------------------
> >>>>>>Info) Multithreading available, 2 CPUs detected.
> >>>>>>Info) OpenGL renderer: Quadro4 980 XGL/AGP/SSE2
> >>>>>>Info) Features: STENCIL STEREO RN MDE MTX PP
> >>>>>>Info) OpenGL Programmable shading is NOT available.
> >>>>>>Info) Textures: 2-D (4096x4096), 3-D (512x512x512), Multitexture (4)
> >>>>>>
> >>>>>>1.8.2 ("slow rendering")
> >>>>>>
> >>>>>>Info) http://www.ks.uiuc.edu/Research/vmd/
> >>>>>>Info) Email questions and bug reports to vmd_at_ks.uiuc.edu
> >>>>>>Info) Please include this reference in published work using VMD:
> >>>>>>Info) Humphrey, W., Dalke, A. and Schulten, K., `VMD - Visual
> >>>>>>Info) Molecular Dynamics', J. Molec. Graphics 1996, 14.1, 33-38.
> >>>>>>Info) -------------------------------------------------------------
> >>>>>>Info) Multithreading available, 2 CPUs detected.
> >>>>>>Info) OpenGL renderer: Quadro4 980 XGL/AGP/SSE2
> >>>>>>Info) Features: STENCIL STEREO RN MTX
> >>>>>>Info) Textures: 2-D (4096x4096), 3-D (512x512x512), Multitexture (4)
> >>>>>>vmd >
> >>>>>>
> >>>>>>Is there any rational explanation for this behaviour?
> >>>>>>Thanks a lot,
> >>>>>>
> >>>>>>Joachim Greipel
> >>>>>>
> >>>>>>Medizinische Hochschule Hannover
> >>>>>>Germany
> >>>>>
> >>>>>
> >

-- 
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