VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Sat Feb 10 2007 - 23:58:18 CST

Hi,
  You have a mix of issues with the systems you've tested below.
One of the cards is actually incapable of supporting GLSL fragment
shaders, the other two are probably just encountering a driver bug.

I'll go through each of the ones you listed and explain the likely cause:

On Sat, Feb 10, 2007 at 12:59:42PM +0100, Pietro Amodeo wrote:
> 1) Toshiba laptop:
[...]
> Info) OpenGL renderer: GeForce4 460 Go/AGP/SSE2
> Info) Features: STENCIL MDE CVA MTX PP PS GLSL(OV)
> Info) GLSL rendering mode is NOT available.
> Info) Textures: 2-D (2048x2048), 3-D (64x64x64), Multitexture (2)

This machine cannot run OpenGL Shading Language fragment programs
at all, because the hardware predates floating point shaders.
I believe this was true of all of the NVIDIA 4x00 series cards
if I recall correctly, and since this one is one of the mobile versions
of that series it undoubtably has the same limitation. These will not
be able to run anything but the oldest form of programmable shaders,
the ARB vertex/fragment program extensions variety, which don't allow
branching etc, as I recall. These can't really be made to work for
the complex shading and texture mapping that VMD requires. They work
fine for normal OpenGL and for the earlier programmable shading used by
some of the older games however.

> 2) Workstation 1:
[...]
> Info) OpenGL renderer: Quadro FX 3000/AGP/SSE2
> Info) Features: STENCIL MSAA(16) MDE CVA MTX PP PS GLSL(OVF)
> Warning) GPU driver failed to compile shader:
> Warning) /usr/local/lib/vmd/shaders/vmd
> Warning) This GPU/driver is buggy, or doesn't fully implement GLSL.
> Warning) Set environment variable VMDGLSLVERBOSE for more info.
> Info) GLSL rendering mode is NOT available.
> Info) Textures: 2-D (4096x4096), 3-D (512x512x512), Multitexture (4)

This one is most likely a bug in the current driver you're running,
as I believe that card is new enough. One thing to check which
has caused problems with with some of the NVIDIA drivers in the past
is to see whether you've enabled internationalization on your system.
Apparently some of the GLSL compilers do the wrong thing when the system
runs in an internationalized mode when confronted with "." versus "," in
equations etc. The solution (if this is the problem) is to disable
the international language settings on your machine and set it back
to the "C" locale. This is not a problem I've run into personally,
but since you're writing from Italy, I felt it wise to mention this
is a widely reported problem on some of the graphics driver support
forums.

Beyond internationalization problems, GLSL bugs seem to
vary by cards, as I have a GeForce 8800 running that same driver which
does not experience this problem. Try setting VMDGLSLVERBOSE to 1 and
see what errors it emits. At the very least it will help narrow down
whether you've run into an internationalization problem, or one of
various other types of GLSL compiler bugs we've seen previously.
You might also try one of the earlier drivers.
If you like I can dig up some of the versions I've tested
that were relatively bug-free. It's a bit of a never ending task to
report bugs in the video drivers. Getting GLSL bug-free has been hard
for the video driver people for some reason. Often during the same
driver release cycle when one bug is fixed, a new one crops up in an
area that was previously trouble-free.

> 3) Workstation 2:
[...]
> Info) OpenGL renderer: Quadro FX 1400/PCI/SSE2
> Info) Features: STENCIL MDE MTX NPOT PP PS
> Info) GLSL rendering mode is NOT available.
> Info) Textures: 2-D (4096x4096), 3-D (512x512x512), Multitexture (4)
> Info) Opening Spaceball on port: /dev/ttyS0
> Found 72 plugins or data handlers in directory
> '/usr/local/lib/vmd/plugins/LINUX/molfile'.

I'm not familiar with the Quadro FX1400, but it's a current NVIDIA
product, so I suspect this too is simply a driver bug, probably
the same issue as the card above. If you like I'll dig up
driver version numbers that have worked well in our laboratory.

> The same outputs were obtained using either downloaded and in-home
> compiled binaries.

Absolutely, this is what i would expect. The issue is that the GLSL
compiler (which is part of the video driver) is buggy and is not
accepting valid GLSL shader code. It's annoying, I know. The main
reason that older versions of VMD didn't introduce GLSL support way
back in 2003 was because there were so many bugs in the drivers
on cards that most people used. Even today, the VMD GLSL shaders
use a very simple subset of the full GLSL standard due to the
bugs in the drivers triggered when we use more of the features.

> However, a long-lasting problem with my Spaceball 4000FX is fixed, because
> now it is fully recognized and active without any previous "acivation" of
> the corresponding driver.

That's interesting. I wonder why it behaves differently with your
compilation than with ours. Perhaps your runtime libraries and the
ones we linked with don't get a long, or the ones we compiled with
don't do well with internationaliation.

  John Stone
  vmd_at_ks.uiuc.edu 

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