From: Dan Strahs (dstrahs_at_pace.edu)
Date: Tue Sep 20 2005 - 18:04:15 CDT

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