Robert, one quick clarification: does the new max-PagedLOD scheme work in conjunction with expiry settings, or are they mutually exclusive techniques? I have not studied the new code yet.
Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Mon, Dec 15, 2008 at 9:40 AM, Robert Osfield <robert.osfi...@gmail.com>wrote: > Hi All, > > A month of so back I developed a new expiry scheme for DatabasePager > that works to ensure that number of PagedLOD in memory at any one time > does not exceed a specified target maximum number of PagedLOD. The > new scheme allows the number of PagedLOD in memory to raise until it > hits the target maximum number of PagedLOD, and then if any new > PagedLOD's are request non visible PagedLOD's are then expired to > balance the total number in memory. > > The new scheme contrasted the previous scheme of expiry delay and > expiry frames as these only expiry non visible PagedLOD subgraphs if > they hadn't be viewed for a maximum number of seconds or frames, > neither of these schemes could directly limit the total resources > used, and if you moved the eye point quickly it was possible to reach > quite high numbers of PagedLOD in memory as new subgraphs in wouldn't > be balanced by expiry of non visible ones. > > The new scheme offers far better control on how memory your > application will require, so should be able to cope better with a wide > range of usage models and machines. Another advantage of the new > scheme is that if you do have sufficient memory you can allow the > target maximum to go up and then you can keep lots of data in memory > so that if you are moving around the terrain quickly from place to > place and then returning you'll not have to wait for data to paged in > as it'll already be in memory. A further advantage it that it isn't > isn't either time or frame based you don't need to select a scheme the > works best for frame driven or event driven apps, one setting works > just the same for both types of applications. > > -- > > The other change I've made, and this one it potentially more > contentious is that I've disable the pre compile feature of the > DatabasePager by default. The pre compile feature is used to limit > the number of OpenGL objects that are compiled/deleted per frame, this > feature is meant to reduce the liklihood of frame drops due a new > subgraph being merged that has so much OpenGL data to compile that > introducing it causes a frame drop. The down side of pre-compile is > that it increases the latency between when a tile is first requested > and when it's finally merged. With my own testing on databases I rare > see frame drops with not havin pre-compile enabled, but do notice the > extra latency especially when moving to new regions rapidly so only > balance I've made the call that we'll better visual quality from out > databases with pre compile disabled. > > Now I say it's contentious as making this change may make your > applications more prone to frame drops, and if this is critical for > you then this change is not ideal. It's also only mean own testing > across the machines I have to suggests to me that frame drop issue is > not as critical as it once was - the pre compile used to essential to > avoid frame drops when I first wrote the DatabasePager back in the > early days of the OSG. On you own machines/OS's things may be > different, the pre compile may still be the best default for you. It > is only the defaults I've changed so you still enable pre compile > either via the OSG_DO_PRECOMPILE env var or > DatabasePager::setDoPreCompile(true). > > -- > > With these two changes my hope is that DatabasePager will now work > better out of the box for more OSG users that the previous settings. > Whether it achieves this or not is something I can say, I need > feedback from the community on how well the new defaults pan out in > end users applications or their machines with their databases. > > So please check out svn/trunk or the next dev release (2.7.8 due in a > couple of days) and let me know. > > Thanks, > Robert. > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
