Re: [Flightgear-devel] weird memory bloat
On 01/30/2009 03:44 AM, Tim Moore wrote: > Give the new version a try please. All better now. Thanks. VIRT = 460 peak, 440 steady state. Readers who aren't closely following the context should note that we are referring to the "next" branch of _simgear_. > Point of information: there are 2.6 million trees in the scene when starting > at > KASE. That is an insane number! It is impressive that the ShaderGeometry > pseudo-instancing mechanism can handle this many models. Jeepers. So the bloat was only a couple hundred bytes per tree. It's impressive that it wasn't much, much worse, in terms of memory and/or CPU usage. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weird memory bloat
John Denker wrote: ... > Alas after doing that, the memory bloat remains, as bad as ever. > I saw it peak at 905 megs at KASE before falling back to 888 megs. > > While were in the neighborhood: I did a fresh cvs update and the > symptoms are the same, so we can't blame it on non-authoritative > sources. > > All this is with OSG 2.7.7. Debian etch. > > On 01/28/2009 01:18 AM, Tim Moore wrote: > >>> I'm seeing about 10% less virtual memory usage with the current next branch >>> compared to the 1.9 release. > > Puzzling. I believe I've fixed this in CVS and my git next branch. The extra memory usage comes from putting all the trees into OpenGL display lists. The actual extra memory consumed is very graphics-hardware-and-driver-dependent, so some people were seeing improved performance and not much more memory usage, others were seeing a catastrophic memory blow-up. The fix is to not put trees in display lists; there are just too many. I made some other changes to reduce the memory footprint of the trees as well. >>> How were you running flightgear (aircraft, starting location, etc.)? > > That's a sensible and relevant question. I observe problem to be > not particularly aircraft-sensitive (the default c172p will do) ... > but it is definitely location-sensitive. > KSFO ... 613 MB steady state > KASE ... 905 MB peak, 888 steady state Point of information: there are 2.6 million trees in the scene when starting at KASE. That is an insane number! It is impressive that the ShaderGeometry pseudo-instancing mechanism can handle this many models. > > > The bloat is 100% reproducible chez moi when there are no options > other than --airport. Sometimes "top" misses the peak, but the > steady state is bad enough. > > Similarly the lack of bloat is 100% reproducible with older versions. Give the new version a try please. Tim -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weird memory bloat
Thanks Michael, I'll try it out ... On Wed, Jan 28, 2009 at 6:04 PM, Michael D. Smith wrote: > syd adams wrote: > > I noticed a change too after updating yesterday > > I tried several times to fly online around KSFO , and after 10 - 15 > > minutes , I came to a stop midair while the hard drive thrashed away > > ... I finally had to kill X to get back some control over my system ... > > It definately wasn't like this before the update ... I only have 512 > > megs of memory , and my dockapp shows Im pretty much at the limit with > > FG > > > > So my question is , how could I track this down? I've never used any > > debugging tools . Looks like a good time to try , just not sure which > > . (on Linux) > > Cheers > > > > > > > -- > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > > > > > ___ > > Flightgear-devel mailing list > > Flightgear-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > I have always used gdb and strace for debugging FlightGear. gdb -args > fgfs will bring you into the gdb interface, run will start > it, bt is for backtrace, etc. Reading the man page for gdb would be best. > > The only time I recall this happening to me was because I was completely > out of memory (I had 376 MBs at the time) and had to deal with it by > increasing swap size and dealing with the extra lag from using swap. > > I would help test with this but my computer used for FlightGear died so > I am stuck with an onboard intel graphics chip that isn't worth a lick. > > -- > Michael Smith (mdsmith2) > > > > -- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weird memory bloat
syd adams wrote: > I noticed a change too after updating yesterday > I tried several times to fly online around KSFO , and after 10 - 15 > minutes , I came to a stop midair while the hard drive thrashed away > ... I finally had to kill X to get back some control over my system ... > It definately wasn't like this before the update ... I only have 512 > megs of memory , and my dockapp shows Im pretty much at the limit with > FG > > So my question is , how could I track this down? I've never used any > debugging tools . Looks like a good time to try , just not sure which > . (on Linux) > Cheers > > > -- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > > > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > I have always used gdb and strace for debugging FlightGear. gdb -args fgfs will bring you into the gdb interface, run will start it, bt is for backtrace, etc. Reading the man page for gdb would be best. The only time I recall this happening to me was because I was completely out of memory (I had 376 MBs at the time) and had to deal with it by increasing swap size and dealing with the extra lag from using swap. I would help test with this but my computer used for FlightGear died so I am stuck with an onboard intel graphics chip that isn't worth a lick. -- Michael Smith (mdsmith2) -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weird memory bloat
I noticed a change too after updating yesterday I tried several times to fly online around KSFO , and after 10 - 15 minutes , I came to a stop midair while the hard drive thrashed away ... I finally had to kill X to get back some control over my system ... It definately wasn't like this before the update ... I only have 512 megs of memory , and my dockapp shows Im pretty much at the limit with FG So my question is , how could I track this down? I've never used any debugging tools . Looks like a good time to try , just not sure which . (on Linux) Cheers -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weird memory bloat
On Wed, Jan 28, 2009 at 11:31 AM, John Denker wrote: > On 01/28/2009 10:20 AM, Tim Moore wrote: > > > Alternatively, try > > starting with /sim/rendering/random-vegetation set to false. > > Bingo. > > That makes a huge difference. VIRT = 371 instead of 888. > > > I imagine there are a lot of trees around KASE... > > Yes. Hey Tim, If you are in poking around the random tree code, here's something else I noticed. The original OSG implementation had a nice feature where it phased in tree'd areas little by little ... so as you approached an area, you might see one or two trees at some medium distance, and as you flew closer, more and more trees filled in the spaces in between until you got to full coverage when you were close to an area. This was subtle enough that often you didn't even notice the trees being added and removed as you flew. Lately, with some of the tree related patches and changes, I'm seeing whole blocks of trees pop in and out at once, which does lead to a distracting "popping" effect. I really liked the old subtle way of blending in trees one bit by bit as you got closer. It seems like it's only half broke at the moment, sometimes I see both happening in different areas of the scenery. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weird memory bloat
On 01/28/2009 10:20 AM, Tim Moore wrote: > Alternatively, try > starting with /sim/rendering/random-vegetation set to false. Bingo. That makes a huge difference. VIRT = 371 instead of 888. > I imagine there are a lot of trees around KASE... Yes. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weird memory bloat
On Wednesday, 28. January 2009, John Denker wrote: > Ridiculing the bug report will not make the bug go away. I did not want to ridicule the report in any way. Apologies if it came like that. I just wanted to point out, that measuring memory usage unfortunately is not as easy as it looks (no, the memory usage number, Windows is displaying is not the whole truth either). I can't remember reading something about the swapping in your report, but that may just be my memory. Of course you're right: the swapping is a clear indicator. Had my own problems with FG's memory usage, too. But a friend solved it for me by giving me 2GB additional RAM as a birthday present. Stefan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weird memory bloat
John Denker wrote: > On 01/28/2009 09:55 AM, Stefan Seifert wrote: > >> "bloat" is a hard word for something, which you did not even measure yet. >> The >> VIRT column of top is basically useless for getting the memory usage. It's >> just the virtual address space allocated to that process. That includes: >> * memory allocated with malloc but not yet used, which means that there is no >>physical RAM used for it >> * mmap'ed files >> * shared memory >> and I'm sure some more which I'm not thinking of. >> >> According to VIRT, amarok uses > 730MB on my system which is a quite >> ridiculous number. >> >> If you're interested in memory usage of a process, a _start_ is the RES >> column. It's far nearer to the "truth" even though it does not count swap >> usage of the process. But if FG causes swapping, you don't need top to tell >> you :) That'd be obvious. > > Uhhh, the bloated versions of FG do cause swapping. > And yes, it is plenty obvious. > > It's hard to shoot an approach in the up-to-date version > of FG because if FG is running acrobat is swapped out and > I can't look at the approach plate. And it's hard to > cut-and-paste measurements into email because the mailer > is swapped out. > > All indications are that FG is using a high percentage > of its VIRT. > > Older versions still run just fine. > > Ridiculing the bug report will not make the bug go away. No doubt. Before I dive into this later this evening, can you try reverting simgear to before the commit "Rewrite ShaderGeometry to use display lists and OSG primitives" and see if that makes a difference to you? Alternatively, try starting with /sim/rendering/random-vegetation set to false. If that does make a difference, make sure you are up-to-date with the very latest simgear and see if you still see this bloat. I imagine there are a lot of trees around KASE... Tim -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weird memory bloat
On 01/28/2009 09:55 AM, Stefan Seifert wrote: > "bloat" is a hard word for something, which you did not even measure yet. The > VIRT column of top is basically useless for getting the memory usage. It's > just the virtual address space allocated to that process. That includes: > * memory allocated with malloc but not yet used, which means that there is no >physical RAM used for it > * mmap'ed files > * shared memory > and I'm sure some more which I'm not thinking of. > > According to VIRT, amarok uses > 730MB on my system which is a quite > ridiculous number. > > If you're interested in memory usage of a process, a _start_ is the RES > column. It's far nearer to the "truth" even though it does not count swap > usage of the process. But if FG causes swapping, you don't need top to tell > you :) That'd be obvious. Uhhh, the bloated versions of FG do cause swapping. And yes, it is plenty obvious. It's hard to shoot an approach in the up-to-date version of FG because if FG is running acrobat is swapped out and I can't look at the approach plate. And it's hard to cut-and-paste measurements into email because the mailer is swapped out. All indications are that FG is using a high percentage of its VIRT. Older versions still run just fine. Ridiculing the bug report will not make the bug go away. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weird memory bloat (was: engine reconfiguration?)
On Wednesday, 28. January 2009, John Denker wrote: > On 01/28/2009 02:25 AM, Erik Hofman wrote: > > I didn't check it myself yet, but every once in a while I have to do a > > 'make clean' before 'make install' for this sort of things (both for > > Simgear and FlightGear) > > Good advice; thanks. > > Alas after doing that, the memory bloat remains, as bad as ever. > I saw it peak at 905 megs at KASE before falling back to 888 megs. "bloat" is a hard word for something, which you did not even measure yet. The VIRT column of top is basically useless for getting the memory usage. It's just the virtual address space allocated to that process. That includes: * memory allocated with malloc but not yet used, which means that there is no physical RAM used for it * mmap'ed files * shared memory and I'm sure some more which I'm not thinking of. According to VIRT, amarok uses > 730MB on my system which is a quite ridiculous number. If you're interested in memory usage of a process, a _start_ is the RES column. It's far nearer to the "truth" even though it does not count swap usage of the process. But if FG causes swapping, you don't need top to tell you :) That'd be obvious. Stefan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] weird memory bloat (was: engine reconfiguration?)
On 01/28/2009 02:25 AM, Erik Hofman wrote: > I didn't check it myself yet, but every once in a while I have to do a > 'make clean' before 'make install' for this sort of things (both for > Simgear and FlightGear) Good advice; thanks. Alas after doing that, the memory bloat remains, as bad as ever. I saw it peak at 905 megs at KASE before falling back to 888 megs. While were in the neighborhood: I did a fresh cvs update and the symptoms are the same, so we can't blame it on non-authoritative sources. All this is with OSG 2.7.7. Debian etch. On 01/28/2009 01:18 AM, Tim Moore wrote: >> I'm seeing about 10% less virtual memory usage with the current next branch >> compared to the 1.9 release. Puzzling. >> What revisions of sg and fg were you running a few >> weeks ago? That last well-behaved version I can identify with confidence is a pull from Pigeon's repository, with the following HEAD: commit f489aed160cfa57bc8005cb4feb7105bc919b247 Author: Melchior Franz Date: Sun Jan 11 00:49:39 2009 + hits are consumed by default (prevents actions in lower dialogs) >> How were you running flightgear (aircraft, starting location, etc.)? That's a sensible and relevant question. I observe problem to be not particularly aircraft-sensitive (the default c172p will do) ... but it is definitely location-sensitive. KSFO ... 613 MB steady state KASE ... 905 MB peak, 888 steady state The bloat is 100% reproducible chez moi when there are no options other than --airport. Sometimes "top" misses the peak, but the steady state is bad enough. Similarly the lack of bloat is 100% reproducible with older versions. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
