From: John Stone (johns_at_ks.uiuc.edu)
Date: Wed Sep 21 2005 - 10:36:03 CDT

Dan,
  I don't know if you have any budget for upgrading your video card,
but if you do, it's surely the cheaper option in terms of time/money/science
than suffering through the limitations of an underpowered video card
if you plan to make a lot of electrostatic potential figures. If you
have the means, I'd say "do not pass GO, go directly to your nearest
computer store and get a real video card ". As others have already mentioned,
the nVidia cards are likely the most stable option for Linux.
A quick scan through www.pricewatch.com indicates that one can find an
nVidia GeForce FX 6800 class card for $300 or less. If you plan to work
with large potential maps, you'll want a card of that class 256MB or 512MB
of texture memory. If you're operating system agnostic, then there are many
other vendors and cards to choose from that perform ok on Windows, but since
you're using Linux, the best option is pretty clear.

  John Stone
  vmd_at_ks.uiuc.edu
 
On Tue, Sep 20, 2005 at 07:04:15PM -0400, Dan Strahs wrote:
>
> Thanks for the reply, John.
>
> The minitower computer is fairly recent vintage: it's a Dell Optiplex
> GX270 with onboard 82865G chipset. This was the university's standard
> desktop configuration in late 2003; I have a couple of these boxes in my
> lab. While the machine I'm using has an additional 512Mb of videoRAM, the
> BIOS has an 8Mb limitation on the preallocated videoRAM. I had always
> intended to use these machines for graphics visualization, but the specs
> don't seem so hot anymore.
>
> If you look at the following messages from the XFree86.log output, you can
> see that the system appears to allocate memory based on this 8Mb
> limitation:
>
> (II) I810(0): VESA VBE OEM Product: Intel(r)865G Graphics Controller
> (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0
> (II) I810(0): Integrated Graphics Chipset: Intel(R) 865G
> (--) I810(0): Chipset: "865G"
> (--) I810(0): Linear framebuffer at 0xE8000000
> (--) I810(0): IO registers at addr 0xFEB80000
> (II) I810(0): detected 8060 kB stolen memory.
> (II) I810(0): I830CheckAvailableMemory: 441340 kB available
> (II) I810(0): Will attempt to tell the BIOS that there is 12288 kB
> VideoRAM
> (WW) I810(0): Extended BIOS function 0x5f11 not supported.
> (II) I810(0): BIOS view of memory size can't be changed
> (this is not an error).
> (--) I810(0): Pre-allocated VideoRAM: 8060 kByte
> (**) I810(0): VideoRAM: 30000 kByte
> (==) I810(0): video overlay key set to 0x83e
> (**) I810(0): page flipping disabled
> (--) I810(0): Maximum frambuffer space: 29848 kByte
> .
> .
> .
> (II) Loading sub module "int10"
> (II) LoadModule: "int10"
> (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a
> (II) I810(0): initializing int10
> (II) I810(0): Primary V_BIOS segment is: 0xc000
> (II) I810(0): VESA BIOS detected
> (II) I810(0): VESA VBE Version 3.0
> (II) I810(0): VESA VBE Total Mem: 8000 kB
>
> If there's any hope of getting this working with the current hardware,
> please let me know! No doubt I can improve these boxes with an ATI
> Rage or Radeon graphics card, but that would take additional time I'm
> loath to commit (given that my collaborator is waiting for the
> electrostatics data!)
>
> Dan Strahs
>
>
> On Tue, 20 Sep 2005, John Stone wrote:
>
> >
> > Dan,
> > DRI should give you a nice speed boost over what you had going before.
> > The problem you have now is that your graphics board is saying
> > that it can only render a 3-D texture map with max dimensions 128x128x1,
> > which is useless for the purpose of coloring by volume, and while I'll
> > have automatic downsampling code, smashing the Z dimension to a single
> > voxel clearly doesn't do you much good for displaying potential. :-)
> >
> > The checkerboard pattern indicates that VMD was not able to send the
> > 3-D texture map to your video board, your video board balked, so that's
> > the "failed texture download" image it displays. (I could have emitted
> > text messages in the VMD console, but when the low-level OpenGL code
> > hits a brick wall, you can end up printing thousands of warnings, so I chose
> > to use the checkerboard pattern instead.)
> >
> > If your video board really can't handle a 3-D texture map bigger
> > than 128x128x1, then you're basically out of luck as far as using the
> > built-in color-by-volume feature goes, leaving you with the option of
> > doing a script based approach instead.
> >
> > Out of curiosity, how old is the video board/laptop you're using?
> > I'd highly recommend sending a bug report or feature request to Intel
> > about this since not supporting 3-D texturing clearly makes your graphics
> > accelerator much less useful.
> >
> > John
> >
> > On Tue, Sep 20, 2005 at 05:40:09PM -0400, Dan Strahs wrote:
> > >
> > > Well, I think I have the direct rendering working. Thank you John and
> > > Axel: your suggestions over the past 24 hours have been invaluable. As a
> > > result, DRI is working. I have uploaded both the XF86Config and the output
> > > from glxinfo at these links:
> > >
> > > http://storage.pace.edu/DStrahs/Research/XF86Config?uniq=-o8h7f3
> > >
> > > http://storage.pace.edu/DStrahs/Research/glxinfo?uniq=-o8h7f8
> > >
> > > VMD also is happier:
> > > Info) Multithreading available, 1 CPU detected.
> > > Info) OpenGL renderer: Mesa DRI Intel(R) 865G 20021115
> > > Info) Features: STENCIL RN CVA MTX
> > > Info) GLSL rendering mode is NOT available.
> > > Info) Textures: 2-D (1024x1024), 3-D (128x128x1), Multitexture (2)
> > >
> > > However, the "Color Surface by Volume" function is still on the fritz. It
> > > looks wrong. The protein is mostly colored a mottled darkred/white using
> > > the RWB color scale model, even though the region of the protein is
> > > positively charged. Altering the min/max/midpoint of the scale has little
> > > effect. In comparison, isocontours are displaying the correct potential.
> > >
> > > If you're curious, I could generate some lowres JPEGs so you could see the
> > > effect. It doesn't look like a standard 2D "checkerboard", so I don't
> > > believe that I'm dealing with a memory issue.
> > >
> > > Any other ideas? If I can't get this to work soon, then I'll finish
> > > developing that script I outlined in a previous post.
> > >
> > > Dan Strahs
> > >
> > > On Tue, 20 Sep 2005, John Stone wrote:
> > >
> > > > Axel,
> > > > I'm planning to add some code that'll automatically downsample the
> > > > texture map to fit into the available texture memory. If Dan can get
> > > > his video driver working correctly, I should be able to give you guys a
> > > > binary that will cope with the small 3-D texture memory on those cards.
> > > >
> > > > John
> > > >
> > > > On Tue, Sep 20, 2005 at 09:17:54PM +0200, Axel Kohlmeyer wrote:
> > > > > On Tue, 20 Sep 2005, Dan Strahs wrote:
> > > > >
> > > > > dan,
> > > > >
> > > > > DS> I am having a problem with coloring my MSMS-generated surface by
> > > > > DS> electrostatic potential. I have APBS installed; in the potential file I've
> > > > > DS> uploaded, I know that the maximum/minimum run from approx. -1500 to +1000.
> > > > > DS> Yet my surface remains stubbornly white. I've loaded the potential as a DX
> > > > >
> > > > > that usually means, that your setup does not provide the minimum
> > > > > requirement for colormapped surfaces, that VMD requires.
> > > > >
> > > > > DS> format, I've tried both the graphics trajectory tab and the "color
> > > > > DS> scale method RWB" "color scale min -5.0" "color scale max 5.0": no change.
> > > > > DS> Altering the range from -0.001/0.001 to -1500/1000 has no effect.
> > > > > DS>
> > > > > DS> I've enabled the 3d_accelerator: I have Dell GX270 with an Intel 82865G
> > > > > DS> chipset on the motherboard. Since I'm running Linux (RH9), I'm using
> > > > > DS> XFree86-4.3.0-2.90.55. I have DRI enabled with the i830 driver - the i830
> > > > > DS> kernel module is loaded.
> > > > >
> > > > > first off, if you update to a recent driver from intel, the
> > > > > respective module should be named 'gdg'.
> > > > >
> > > > > DS>
> > > > > DS> VMD starts with:
> > > > > DS> Info) Multithreading available, 1 CPU detected.
> > > > > DS> Info) OpenGL renderer: Mesa GLX Indirect
> > > > > DS> Info) Features: RN MTX
> > > > >
> > > > > please check your X configuration. you do _not_ have DRI enabled.
> > > > > if you had, you would see something like this:
> > > > >
> > > > > Info) OpenGL renderer: Mesa DRI Intel(R) 852GM/855GM 20040331 x86/MMX/SSE2
> > > > > Info) Features: STENCIL RN MDE CVA MTX
> > > > >
> > > > > i have a centrino laptop with intel graphics here, also running RH9.
> > > > > for that to work reasonably, i had to update the driver with newer
> > > > > software from intel. but still that did not make color mapping work
> > > > > for that machine. i _do_ get some colorization, but it is something
> > > > > that is supposed to indicate that there is a problem with memory for
> > > > > textures. for more details, please see:
> > > > > http://www.ks.uiuc.edu/Research/vmd/mailing_list/vmd-l/4734.html
> > > > >
> > > > > DS> Info) GLSL rendering mode is NOT available.
> > > > > DS> Info) Textures: 2-D (2048x2048), Multitexture (6)
> > > > > DS>
> > > > > DS> Is there some clue here about what's happening? I've uploaded the makefile
> > > > > DS> output from the VMD and plugins compile (with configure options LINUX
> > > > > DS> OPENGL FLTK TK IMD TCL PTHREADS ACTC PYTHON NUMPY) at these links:
> > > > > DS> http://storage.pace.edu/DStrahs/Research/make.log?uniq=-o8hxtn
> > > > > DS> http://storage.pace.edu/DStrahs/Research/log.LINUX?uniq=-o8hxts
> > > > > DS>
> > > > > DS> I would be grateful for any help (other than recommending a different
> > > > > DS> graphics card).
> > > > >
> > > > > sorry, but if you look through the mailing list archives,
> > > > > you'll learn that there are next to no alternatives for that
> > > > > due to the way surface mapping is implemented in VMD.
> > > > >
> > > > > axel.
> > > > >
> > > > > DS>
> > > > > DS> Dan Strahs
> > > > > DS>
> > > > > DS>
> > > > >
> > > > > --
> > > > >
> > > > > =======================================================================
> > > > > Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer_at_theochem.ruhr-uni-bochum.de
> > > > > Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673
> > > > > Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045
> > > > > D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/
> > > > > =======================================================================
> > > > > If you make something idiot-proof, the universe creates a better idiot.
> > > >
> > > >
> > >
> >
> >
>

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