VMD-L Mailing List

From: Pietro Amodeo (pamodeo_at_icb.cnr.it)
Date: Mon Nov 19 2012 - 20:18:27 CST

Hi,

just a late-night, last-minute update. Both suspend/resume and OpenGL
issues are a little bit more involved and intertwined than expected. In
fact:
a) FPS and window size are related but not in a simple proportional
way, since varying either height or width or both leads to apparently
erratic changes in FPS that with no mol displayed or with the infamous
330-res protein in line representation range from 5 to 60 (approx. 1 to
30 in new cartoon or surf mode)! The result is similar when using GLSL
shader or not. When resizing a window, FPS rate varies almost
continuously with no apparent regularity and going back to
(approximately) the starting size usually results in a totally different
FPS...
b) at least the suspend/resume issue initially seemed simply a power
management-related problem, as you suggested, in particular depending on
the power-saving mode that was active at the suspend time. In fact,
suspending when vmd was active with (currently) optimal FPS rate (nvidia
panel indicating max performance settings) gave back the same
performance after resuming the system, while suspending with the system
in its lower graphic performance setting state led to the (now
unfortunately usual) very slow vmd behaviour after restarting the
program (I had to log off vmd to bring nvidia setting to power-saving
settings, otherwise even with no mol loaded it always stays in max
performance mode), although nvidia panel showed max performance settings
soon after launching vmd. HOWEVER, when I went playing with window size,
FPS rate started again its erratic cycling, with the difference that
apparently it took many more attempts to recover max performances (60 on
line/30 on cartoon), initially (1-2 minutes) peaking at 15/8 or 30/15
only.

Could they all represent memory-related issues, possibly suggesting
wrong/slow refresh/cleaning of GPU memory after changes in graphic
state/activity?

Anyway, I'll wait your return to test whatever you may consider useful
to understand and possibly fix these very strange issues.

Cheers,
Pietro

On Mon, 19 Nov 2012 18:28:54 -0600, John Stone wrote:
> Hi,
> The performance loss that you observe after a suspend-resume
> cycle is certainly a driver-related issue of some kind. You might
> need to adjust your driver power management settings, I wonder if
> this is an issue of the GPU being left in power-saving
> low-speed-clock
> mode after the resume, or if its something more complex. Given that
> an X restart doesn't cure it, I would say it seems certain to be a
> driver
> level issue.
>
> You had mentioned that performance varies substantially with the
> size of the OpenGL window. To me, that symptom would be related
> either to the GLSL shading load (when GLSL is active), or as a result
> of running low on GPU memory. I can give you things to try when I
> return from travels next week.
>
> Cheers,
> John
>
> On Mon, Nov 19, 2012 at 09:03:38PM +0100, Pietro Amodeo wrote:
>> John,
>>
>> anther update to the strange behaviour of the 8400M GS laptop:
>>
>> 1) I can confirm that with 310.19 drivers suspend mode (that never
>> was
>> a problem with 295.xx and older drivers, since this PC has been
>> suspended for tenths of times between reboots with no performance
>> issues
>> with vmd or other programs) causes severe degradation (4-5 FPS for
>> no
>> molecule) in vmd performances that can't be cured just with a X
>> restart,
>> but requires a PC reboot;
>>
>> 2) if the vmd graphic window is (even slightly) resized,
>> performances
>> are terribly affected, since with the solvated 330-residue protein
>> of
>> our previous tests, FPS can either increase from ~12-15 to 20-30
>> (see 3)
>> or drop to 4-5, when, using any representation, the windows is
>> partly
>> obscured by the system menubar. On the contrary, it's not very
>> affected
>> (if any) by overlap with other (I tried terminal) windows;
>>
>> 3) for a given optimal windows size FPS for the 330-residue protein
>> +
>> water/ion varies from 4-5 (all-licorice) to 20 (protein new
>> cartoons-water lines) or 30 (simple representation like all-lines or
>> protein new cartoons-water/ions invisible).
>>
>> I hope these symptoms may be more suggestive to you than they are to
>> me...
>>
>> Cheers,
>> Pietro
>>
>> On Mon, 19 Nov 2012 11:25:48 -0600, John Stone wrote:
>> >Pietro,
>> > One thing I notice is that your GPU only as 128MB of memory.
>> >This is a small enough amount of memory that it could present a
>> >challenge if you've got a few things soaking up GPU RAM.
>> >Have you tried turning off the X11 composite / compiz extension?
>> >The compositing window manager eats GPU memory, so that might
>> >alleviate some of the performance issue you're seeing.
>> >I would try that first thing. If that doesn't work, I could try
>> >giving you a VMD that uses a shallower bit-depth framebuffer and
>> >see if that has any impact.
>> >
>> >Cheers,
>> > John Stone
>> > vmd_at_ks.uiuc.edu
>> >
>> >On Mon, Nov 19, 2012 at 05:25:33PM +0100, Pietro Amodeo wrote:
>> >>Hi John,
>> >>
>> >>On Sun, 18 Nov 2012 22:25:27 -0600, John Stone wrote:
>> >>>Hi,
>> >>> Does VMD print any warnings on this machine when it starts?
>> >>>(e.g. compiz compositing manager)
>> >>
>> >>this is the VMD start printout:
>> >>
>> >>Info) VMD for LINUXAMD64, version 1.9.1 (February 1, 2012)
>> >>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) Free system memory: 3644MB (92%)
>> >>Info) Creating CUDA device pool and initializing hardware...
>> >>Info) Detected 1 available CUDA accelerator:
>> >>Info) [0] GeForce 8400M GS 2 SM_1.1 @ 0.80 GHz, 127MB RAM,
>> KTO,
>> >>OIO, ZCP
>> >>Warning) Detected X11 'Composite' extension: if incorrect display
>> >>occurs
>> >>Warning) try disabling this optional X server feature.
>> >>Info) OpenGL renderer: GeForce 8400M GS/PCIe/SSE2
>> >>Info) Features: STENCIL MSAA(16) MDE CVA MTX NPOT PP PS
>> GLSL(OVFG)
>> >>Info) Full GLSL rendering mode is available.
>> >>Info) Textures: 2-D (8192x8192), 3-D (2048x2048x2048),
>> >>Multitexture
>> >>(4)
>> >>Info) Dynamically loaded 2 plugins in directory:
>> >>Info) /usr/local/lib/vmd-1.9.1/plugins/LINUXAMD64/molfile
>> >>
>> >>It looks the same as before the updates and it differs from that
>> >>shown
>> >>on the GT230M box (apart from obvious differences in memory and
>> >>device)
>> >>only in the GLSL feature that on this latter is GLSL(OVFGS).
>> >>
>> >>>It is quite possible you're hitting a driver bug in the latest
>> >>>driver version.
>> >>
>> >>It's quite possible indeed, since after installing the
>> just-released
>> >>310.19 stable version of the driver things improved. In fact, now
>> >>discontinuities in motion are reduced to a flickering and the FPS
>> >>counter shows from 11 to 18 fps with a protein+water system loaded
>> >>and
>> >>different graphic representations.
>> >>
>> >>>
>> >>>Can you send the startup messages VMD prints on this machine?
>> >>>I'm wondering if your OpenGL installation got damaged during
>> >>>the sequence of upgrades you ran.
>> >>
>> >>In general, I manually update NVidia drivers after linux upgrade
>> and
>> >>reboot in non-graphic mode. In this way I never experienced
>> >>problems,
>> >>except for badly-bugged drivers.
>> >>
>> >>
>> >>Please, let me know if you may need any other info.
>> >>
>> >>Thanks,
>> >>Pietro
>> >>
>> >>>
>> >>>Cheers,
>> >>> John Stone
>> >>> vmd_at_ks.uiuc.edu
>> >>>
>> >>>On Fri, Nov 16, 2012 at 08:44:51PM +0100, Pietro Amodeo wrote:
>> >>>>Hi,
>> >>>>
>> >>>>after a kernel upgrade (to 3.6.6-1) on a Fedora 16 laptop (Intel
>> >>>>Core
>> >>>>Duo, 4GB RAM, NVidia 8400M GS) we had to upgrade NVIDIA driver
>> >>from
>> >>>>295.59 to 304.64. The result is a terribly slow VMD 1.9.1
>> >>>>(practically
>> >>>>unusable) displaying <8 fps with no molecule loaded!!!. Things
>> >>>>slightly
>> >>>>improve with beta driver 310.14 (<=15 fps no mol loaded), but
>> >>>>usability
>> >>>>is still rather poor (not fluid).
>> >>>>
>> >>>>Previously, witn NVidia 295.XX drivers, VMD 1.9.1 worked
>> >>flawlessly
>> >>>>on
>> >>>>the same laptop. However, with 304.64 or 314.14 all other tested
>> >>>>OpenGL
>> >>>>programs works correctly and no error message is issued in
>> >>Xorg.log
>> >>>>or
>> >>>>when starting VMD.
>> >>>>
>> >>>>Moreover, VMD 1.9.1 works flawlessly on a Intel i7+NVidia Gt230M
>> >>>>laptop
>> >>>>with the same FC16+kernel 3.6.6-1 +driver 304.64 combination.
>> >>>>
>> >>>>
>> >>>>Thanks in advance for any hint/help.
>> >>>>
>> >>>>Pietro
>> >>>>On this laptop
>> >>>>--