VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Tue Jun 16 2020 - 12:05:48 CDT

Bart,
  Please update to the new VMD 1.9.4a43 builds I posted last week.
They should eliminate the need for the workaround below and may cure the
other issue you've encountered.

Best,
  John

On Tue, Jun 16, 2020 at 02:29:14PM +0200, Bart Bruininks wrote:
> After some more testing I found a bug which is very likely a result of the
> forced dump. Using trajectory smoothing with the dump causes a hard
> rendering crash. I guess this is caused by the CPU only sending each frame
> once and storing the ones needed for later averaging is not possible in the
> GPU due to the forced dump. So although this solves some issues, it
> probably creates new ones. For now I can get what I need, but frame
> averaging is something we often use in MD simulations and would be a loss
> as a feature.
>
> Workaround for OPTIX memory piling
> bash:
> export VMDOPTIXDESTROYCONTEXT=1
>
> New issue:
> Trajectory averaging causes a hard rendering crash
>
> Op wo 10 jun. 2020 om 18:16 schreef John Stone <johns_at_ks.uiuc.edu>:
>
> > Bart,
> > Great. I'm going to go out on a limb and predict that the cause of
> > the memory consumption is a misbehavior of the OptiX RTX API for on-the-fly
> > geometry buffer release during acceleration structure building:
> > rtGeometryTrianglesSetBuildFlags(geom_hwtri,
> > RT_GEOMETRY_BUILD_FLAG_RELEASE_BUFFERS)
> >
> > As per my other email, I've added an alternative code path for VMD that
> > avoids using that feature, and instead lets VMD manage the RTX triangle
> > geometry buffers itself. Having done so, my performance anomaly problem
> > went away, and I'm wondering if your memory leak issue will go away too.. 

-- 
NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
http://www.ks.uiuc.edu/Research/vmd/