VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Mon Jun 16 2003 - 11:26:06 CDT

Hi all,
  I belatedly realized that my first equation actually underestimated the
amount of video memory required. I forgot to multiply the N antialiasing
samples by 4 bytes per pixel, since they average color and alpha transparency,
and I also forgot to add the memory required by the Z-buffer, and some video
boards support "triple-buffering" modes that maintain yet-another-copy
of the active color buffer for various reasons, and an overlay plane for
the mouse cursor.

The corrected equation should be something more like this, keeping
in mind that this still underestimates the actual amount of required
memory, since video memory blocks must typically be allocated starting and
ending on certain page sizes, and that smaller blocks have to be padded out
to the next nearest size:

 Xres * Yres *
   (
    ((4 bytes per pixel OpenGL color buffer) * (2 for mono, 4 for stereo,
      may need to add 1 for certain types of triple buffering modes
      used on some cards)) +
    (N * 4 more bytes per pixel for multisample antialiasing with N samples)
    (1 or more bytes per pixel OpenGL stencil buffer) +
    (2, 3, or 4 bytes per pixel for 16-bit, 24-bit, or 32-bit Z-buffer)
    (some cards use 1 byte for overlay planes or mouse/cursor planes, though
     these are usually shared by all windows IIRC)
   )

Here are some example VMD OpenGL window sizes and OpenGL
extension/feature combinations to compare:
  1280x1024 window, monoscopic, no antialiasing,
  24-bit Z-buffer, stencil buffer: 15MB of video memory

  1280x1024 window, monoscopic, 4 samples per pixel antialiasing,
  24-bit Z-buffer, stencil buffer: 35MB of video memory

  1600x1200 window, monoscopic, 4 samples per pixel antialiasing,
  24-bit Z-buffer, stencil buffer: 52MB of video memory

  1900x1440 window, monoscopic, no antialiasing,
  24-bit Z-buffer, stencil buffer: 33MB of video memory

  1900x1440 window, monoscopic, 4 samples per pixel antialiasing,
  24-bit Z-buffer, stencil buffer: 73MB of video memory
    
  1280x1024 window, stereoscopic, 2 samples per pixel antialiasing,
  24-bit Z-buffer, stencil buffer: 35MB of video memory
 
  1280x1024 window, stereoscopic, 4 samples per pixel antialiasing,
  24-bit Z-buffer, stencil buffer: 45MB of video memory

  1900x1440 window, stereoscopic, 4 samples per pixel antialiasing,
  24-bit Z-buffer, stencil buffer: 94MB of video memory

As you can see, its pretty challenging for an inexpensive PC video card
to support high-resolution OpenGL windows, even with only 24-bit Z-buffer
precision, etc. I'm sure I've still forgotten a few terms in the equation
above, some hardware is even more limited and can't easily support a
single window that spans as much memory as the example above would indicate,
so often times the practical resolution is much lower than you'd expect
by running the numbers through my little equation above.

  John

On Mon, Jun 16, 2003 at 10:11:33AM -0500, John Stone wrote:
>
> Dear Daniel,
> I have a few answers to your questions regarding antialiasing etc.
>
> 1) Mac stuff
> The MacOS X version of VMD is written slightly differently from the Windows
> and Unix versions presently. Both the Windows and Unix versions use
> hand-written OpenGL windowing code that I developed which allow them to
> access features such as stereoscopic rendering, multisample antialiasing,
> video pixel readback, etc. The MacOS X version of VMD currently uses the
> FLTK GUI toolkit to render its OpenGL window, as a result, the only
> extensions available in MacOS X are those OpenGL extensions that can be
> queried/enabled well after the OpenGL window is initially created.
>
> At present, FLTK doesn't know how to enable stereo on MacOS X, so this
> prevents us from using quad-buffered stereo on the Mac, however Apple doesn't
> yet support full quad-buffered stereo on any of the video cards currently
> available, so this is currently only a minor disadvantage. I haven't
> decided whether it would be best for me to contribute a pile of MacOS X
> patches to the FLTK developers, or if it would be best for me just to
> implement my own hand-written "AquaOpenGLDisplayDevice.C" code to replace
> FLTK in managing the VMD OpenGL window. Up to this point, it hasn't
> mattered much, but soon MacOS X will support many more OpenGL features
> that we will want to use, so I will probably start working on one or the
> other solution soon after MacOS 10.3 becomes available.
>
> Regarding the specific extensions you're having listed on your machine:
> Its not at all surprising to me that your list of OpenGL extensions is
> fairly short. This is also true even on my ATI Radeon 9700-equipped test
> box here in the lab. Apple doesn't yet support 100% of all OpenGL extensions,
> and even if they did, they are constrained by the fact that they use a
> significant amount of video memory for rendering of various Aqua GUI effects,
> so even if they implemented all of them, its possible they would not enable
> them on any but video cards with a significant amount of available memory.
> By the way, the antialiasing used by Aqua is fairly different from
> what is done in OpenGL for 3-D geometry, I believe Aqua's font antialiasing
> code is all done on the host machine, and is not done on the GPU.
>
> 2) Linux stuff:
> I've seen the exact behavior you describe on NVidia cards as well.
> Typically the cause is that beyond a certain window size, the graphics
> board begins to take a serious performance hit because it runs out of
> video memory and starts shuffling pages back and forth between the host
> machine's memory and the on-board graphics memory, or similar operations
> within its on-board memory system. Since you didn't mention what video
> resolution you're running at I can't do the math, but you should consider
> that if the OpenGL features are available, VMD's OpenGL window will use:
> Xres * Yres *
> (
> ((4 bytes per pixel OpenGL color buffer) * (2 for mono, 4 for stereo)) +
> (1 or more bytes per pixel OpenGL stencil buffer) +
> (up to N more bytes per pixel for multisample antialiasing with N samples)
> )
>
> So, for a 1280x1024 window with quad-buffered stereo enabled, stencil buffer
> and we'll say 4 samples per pixel antialiasing, you're already looking at
> burning 32MB of video memory just for the VMD window, not counting any
> of the other windows you've got on the display!!
>
> And that's a pretty conservative estimate that does not include things
> like cached OpenGL display lists, cached vertex arrays, etc. By the time
> you add it all up, its quite easy for VMD to annihilate a 64MB video card,
> particularly if you have anything besides VMD running, or if the X server
> keeps a copy of the rest of the screen in the back buffer for fast
> X redraws....
>
> In our last round of hardware upgrades here in our lab, we bought 128MB video
> boards for all of the Linux PC's specifically to address performance problems
> when running at high resolution. As you can imagine, this issue is even more
> severe if you're running your PC with dual monitors!!!! :-)
>
> Several of our Sun workstations are setup with video boards that have
> 384MB of video memory, so they can do quad-buffered stereo, stencil buffering,
> and multisample antialiasing with between 4 and 16 samples per pixel,
> and they still have plenty of video memory for things like volumetric data,
> (electron density map data -> volume slice rep in VMD), etc.
>
> If in doubt, get a video board with a lot of video memory, it will prevent
> your performance from dropping to zilch with large windows. The only other
> option is to disable features in VMD, which we'd rather not do since we
> try to be very forward looking and agressive in our use of OpenGL features.
>
> Thanks,
> John Stone
>
>
> On Mon, Jun 16, 2003 at 12:45:54PM +0300, Dr. Daniel James White PhD wrote:
> > Hi all,
> >
> > 1)
> > i just wondered if antialiasing is going supported in the OSX VMD1.8.1
> > Since the aqua interface does lots of antialiasing, the OSX is well
> > surely well geared for it,
> > and It would look soooo nice on my flat panel LCD iMac with the NVIDIA
> > GeForce2 MX.
> > Shame that the nice new ribbons don't have nice edges....
> >
> > should there be more open GL extensions available than the ones listed
> > in my VMD startup below?
> > Am I doing something wrong.
> > BTW the native interface looks super! Nice anti aliased menus etc.
> >
> > 2)
> > On my linux machine (ATI RADEON 8500 64 Mb, athalon 2 GHz, RedHat 8.0,
> > Xig summit2.2 Xserver)
> > I see the rendering performance (fps) drops drastically after the
> > openGL window is made larger than a certain size.
> > This does not happen with the OSX version, or with pymol or Bodil on
> > the linux machine.
> > Is this something to do with the video memory getting filled up and VMD
> > having to use virtual memory?
> > and if so why does it not happen with the other software such as pymol
> >
> > Do I just need to tweak my settings?
> >
> > cheers
> >
> > Dan
> >
> > [daniel:~] dan% /Applications/VMD/VMD\
> > 1.8.1.app/Contents/MacOS/VMD.startup; exit
> > Info) VMD for MACOSX, version 1.8.1 (June 15, 2003)
> > 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, 1 CPU detected.
> > Info) OpenGL renderer: NVIDIA GeForce2 MX OpenGL Engine
> > Info) Features: STENCIL RN
> > Info) Textures: 2-D (2048x2048)
> >
> >
> > Dr. Daniel James White BSc. (Hons.) PhD
> > Cell Biology
> > Department of biological and environmental science
> > PO Box 35
> > University of Jyväskylä
> > Jyväskylä FIN 40014
> > Finland
> > +358 (0)14 260 4183 (work)
> > +358 (0)414740463 (mob)
> >
> > http://www.chalkie.org.uk
> > dan_at_chalkie.org.uk
> > white_at_cc.jyu.fi
>
> --
> 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