Board index FlightGear Development Scenery

Random Buildings

Questions and discussion about enhancing and populating the FlightGear world.

Re: Random Buildings

Postby Harald » Tue May 08, 2012 7:17 pm

Hi,

when and how are you generating the content of the tile ? I'm asking because I suppose you handle a whole tile at a time, perhaps several tiles if severall tiles were just loaded. I'm getting 1 fps when this happens ; can you cut the work in pieces and do that over several frames, even minutes if needed to reduce the stutter ?

HJ.
Harald
 
Posts: 179
Joined: Fri Mar 02, 2007 5:30 pm
Location: Strasbourg, France
Version: nightly
OS: Windows 10

Re: FlightGear 2.8.0.rc4

Postby Hooray » Tue Aug 21, 2012 11:44 am

EDIT: http://wiki.flightgear.org/Subsystem-le ... FlightGear
stuart wrote in Tue Aug 21, 2012 11:16 am:If people are seeing excessive memory usage, they should switch the random buildings off.

Yes, I have previously suggested doing exactly that - however, the issue remains that some people apparently still see "excessive" RAM usage: http://flightgear.org/forums/viewtopic. ... 23#p164517

While a "reduced" usage of "just" 8 gb instead of 13 gb of is an improvement, it will obviously be showstopper for most people here who don't have 8 gb of RAM available. It's being reported that due to this, the 32bit binary is basically unusable for extended flights of say more than 30 minutes over well-populated scenery - because it will quickly reach the 32 bit memory limit: http://flightgear.org/forums/viewtopic. ... 23#p164823

And the question is if there's any other related code running under such cirumstances, of this cannot even be related to random buildings in the first place?

Memory usage is a function of the building density and the amount of urban/town scenery that has been loaded, and obviously the definition of "excessive" depends on how much RAM your machine has.
Yes, that's clear - but, is there any way to compute dynamically how much RAM is going to be used by enabling certain settings like density? Even just an approximate estimation would help:

While getting the amount of available/free RAM would obviously be OS-dependent (and need to be implemented for all 3 platforms), it would at least be an option to check the projected memory consumption against the amount of installed/free RAM and warn users accordingly, or even refuse applying certain settings.
Like you say, it is better to prevent users from applying certain settings under such circumstances - i.e. it's all about "usability", and crashing shouldn't be an option either.

We can't therefore provide a useful range for the building density. For some people a density of 0.5 will be too much at KLAX, for others a density of 5.0 will be fine in less populated regions.

Exactly, that's why such a slider should be better directly linked to the estimated RAM usage caused by certain settings - so that people will directly see how much RAM will be used, possibly compared to the amount of free RAM - and maybe some green/yellow/red indicator?

On Linux, getting RAM usage stats, would be fairly simple, as it would just involve fopen()ing /proc/meminfo and copying it to the property tree.
Recent Linux versions, even provide in-depth RAM usage information via /proc/[PID]/smaps
Last edited by Hooray on Thu May 15, 2014 5:09 pm, edited 1 time in total.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FlightGear 2.8.0.rc4

Postby stuart » Tue Aug 21, 2012 12:09 pm

Other reasons for excessive memory usage might be highly detailed custom scenery.

There's no simple way to determine RAM usage by a feature like random buildings as it depends so much on the scenery that will be traversed in the future. That's not deterministic.

James and I have a plan to reduce the memory occupancy of the random buildings, but it'll be a while before it's implemented.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: FlightGear 2.8.0.rc4

Postby Hooray » Tue Aug 21, 2012 12:12 pm

stuart wrote in Tue Aug 21, 2012 12:09 pm:There's no simple way to determine RAM usage by a feature like random buildings as it depends so much on the scenery that will be traversed in the future. That's not deterministic.


Yes, but a simpler option might be to restrict memory allocation to a fixed amount of RAM - so that "random buildings" get assigned no more than say 128 MB - looking at the code, that would just involve tracking previously created (and non deallocated) objects - i.e. ref counting objects X sizeof(object). And whenever the limit is reached, invisible buildings could be dynamically removed to free RAM?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FlightGear 2.8.0.rc4

Postby stuart » Tue Aug 21, 2012 12:29 pm

You will find the code in the usual place. Be my guest.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: FlightGear 2.8.0.rc4

Postby Hooray » Tue Aug 21, 2012 12:38 pm

stuart wrote in Tue Aug 21, 2012 12:29 pm:You will find the code in the usual place. Be my guest.

Not sure if that's intended to be a constructive comment or not, but obviously I was trying to be constructive and didn't mean to annoy you - otherwise, I wouldn't have posted these comments and questions.

Honestly even just knowing if you have already considered or possibly even rejected one of these ideas, would be helpful (and more constructive than just saying "be my guest") ?

Looking at the number of crashes reported due to excessive memory usage, even just showing an error message after exceeding a previously configured memory limit, would be useful, or do you disagree?
De-allocation could then be implemented at a later time.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FlightGear 2.8.0.rc4

Postby stuart » Tue Aug 21, 2012 12:43 pm

It was meant in a constructive way.

I haven't looked into whether it would be possible. Naively the simple workaround is to look at the current memory usage and simply stop generating new buildings when it reaches 90%. The problem is that I'm not sure if we have access to the current real memory (as opposed to addressable space), because we'd want to stop generating buildings before we start swapping to disk.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: FlightGear 2.8.0.rc4

Postby Hooray » Tue Aug 21, 2012 12:59 pm

Yes, that's true - but that's primarily related to the other issue of not being currently able to identify the amount of free RAM, which would be platform-dependent.
And these are two different issues.

That said, shouldn't it suffice to be able to first of all define a "hard" (quota) limit using a property to prevent the system from "over-allocating" ?

Such that users could specify a property to limit RAM allocation and so that the code stops allocating new memory and simply shows a warning message instead or sets a property "random-buildings-ram-limit-exceeded=true", that could also be handled by a Nasal/GUI listener to show a GUI dialog.

Looking at the code, would it suffice to track memory allocated in createRandomBuildings() and obj.cxx ?
Or are there any other places I need to look at ?

Without looking at all of your code, the simplest option would probably be overloading the new operator or even using placement/new (which would track quite a bit more than just buildings)- do you agree? Or do you have a better idea to track allocations done by your code? What about osg::ref_ptr semantics here, is the ownership of your allocated memory transferred to any other system?

Like you say, the next step would then probably be to scale this dynamically, by first of all determining the amount of free RAM - and then, finding a way to cull objects that are no longer used (invisible,out of range)? The question is, if that's not re-inventing the wheel, because OSG probably has already machinery doing exactly that sort of thing?

At the moment, I think the necessary steps are:
  • find a way to configure a hard allocation limit via a property
  • find a way to dynamically determine the amount of free, non-virtual, RAM
  • find a way to free allocated objects based on some configurable heuristics (visibility, range etc)

Anything else?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FlightGear 2.8.0.rc4

Postby stuart » Tue Aug 21, 2012 1:48 pm

Hi Hooray,

(OK - you've got me thinking now ;) )

I think we may be able to limit the memory usage in a much more simplistic way. For all intents and purposes, each building uses a fixed amount of memory. We generate DEBUG level logs of the number of buildings that have been generated, and a couple of runs with different building densities should produce an accurate enough figure for the memory occupancy of a single building.

It should be straightforward to use that same building count along with the per-building memory occupancy figure, to stop generating buildings after a certain memory occupancy is reached.

That doesn't allow us to start generating buildings again later as scenery is unloaded. One might be able to create a sub-class of osg::Group that tracks the number of buildings, and then has a destructor to update the building count.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: FlightGear 2.8.0.rc4

Postby Hooray » Tue Aug 21, 2012 2:02 pm

Hi Stuart,

sorry for probably being a pain in the butt.

It's just that all of us like your random buildings feature, but it's obviously a little unfortunate that there are new people using this who end up seeing the latest FG release crashing with "OpenGL out of memory" errors and things like that.

And until we have found ways to improve this, it would be great to have some workarounds to make the whole thing a little more configurable.

Yes, I also noticed the SG_LOG() statements at the end of computeRandomBuildings() in obj.cxx, I was thinking that maybe this info could be also dumped to the property tree for inspection purposes?

That would make it very straightforward for us to provide a Nasal/XML GUI dialog so that "internal" system stats could be easily inspected by our users and shared with us, even if it's just using the property tree in the beginning. Dumping the info to an XML file would be another interesting option - for debugging reports.

Now, I think your idea sounds interesting, I do realize that it's just a rough estimation, and that it will be affected by the scenery landcover "areas" and materials.xml - but it would certainly be a useful tool.

Having access to internal statistics would definitely be useful - and probably help us improve the system further. And enabling/disabling the allocation-block could also be implemented through a boolean property then, which the system sets automatically once certain heuristics apply - which would not even need to be implemented in C++, it could just as well be a property rule or a Nasal script. The C++ code just needs an option to be told to stop allocating new objects, while ensuring that it publishes internal stats and writes them into the property tree.

What do you think?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FlightGear 2.8.0.rc4

Postby Hooray » Tue Aug 21, 2012 5:19 pm

stuart wrote:
Hooray wrote:looking at the code, that would just involve tracking previously created (and non deallocated) objects - i.e. ref counting objects X sizeof(object).
For all intents and purposes, each building uses a fixed amount of memory. We generate DEBUG level logs of the number of buildings that have been generated, and a couple of runs with different building densities should produce an accurate enough figure for the memory occupancy of a single building.


I just tried this, and it seems to provide sensible values - I just adapted your SG_LOG() debug block at the end of ComputeRandomBuildings() in obj.cxx such that it adds up all buildings via something like
Code: Select all
SG_LOG(SG_TERRAIN, SG_ALERT, "  Allocations: " << (allocated += bin->getNumBuildings() * sizeof(SGBuildingBin::Building)) <<" Bytes");


Now, like you said, the next thing would be subclassing osg::Group such that it may decrement the refcount accordingly, there's already a virtual "childRemoved" method that could be used for this purpose: http://www.openscenegraph.org/documenta ... 1187b813a9

Overall, I feel we are making some real progress here - especially, if the SG_LOG() block could be modified such that it writes all this info by default to the property tree, so that property rules or Nasal could be used to control and inspect the system dynamically via the property browser.

The next thing would then probably be finding out how to cull objects, based on visibility and distance - the code already uses a quadtree for spatial partioning, right?

At least for Linux, getting process-specific RAM usage information is fairly straightforward using smaps, which could probably be also written to the property tree by a little subsystem at 1hz intervals - which would be useful for other systems, too - not just random buildings.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Random Buildings

Postby stuart » Wed Aug 22, 2012 8:55 am

Hi Hooray,

Yes, I think this is all do-able.

We already use Quad-trees to provide spacial LoD, but as I may have mentioned before, the issue isn't really what's visible, but was has been loaded into the OSG space, which is basically all the terrain in the tiles.

I'm currently finishing off a fairly major usability enhancement to allow users to configure their joysticks in-sim. It's pretty neat, and I think will help a lot of new users or those who hit problems with their joystick bindings but don't have the XML skills to edit the bindings directly.

Once I've got that done I'll take a look at this. As I said earlier, it may become less relevant if we improve the overall memory occupancy. The particular approach of generating a single huge OSG mesh for all the buildings may in fact be a dead-end and we may use something closer to the random trees - a relatively small number of buildings (say 60k) instantiated multiple times.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Random Buildings

Postby Hooray » Wed Aug 22, 2012 12:06 pm

stuart wrote in Wed Aug 22, 2012 8:55 am:Once I've got that done I'll take a look at this. As I said earlier, it may become less relevant if we improve the overall memory occupancy. The particular approach of generating a single huge OSG mesh for all the buildings may in fact be a dead-end and we may use something closer to the random trees - a relatively small number of buildings (say 60k) instantiated multiple times.


Thanks for the heads-up, I do understand how this is probably going to be less relevant then.

OTOH, exposing internal stats to the property tree would still seem useful, especially for people wanting to make bug reports, or even just for dynamic "feature-scaling" using Nasal and/or XML-Property Rules. Thus, I feel that even just replacing the SG_LOG() statements with SGPropertyNode->setStringValue(...) would be a good move, as it would help people looking "under the hood" of the system, so to speak.

And like I said earlier, being able to control the behavior of the system (even if that just means disabling/enabling allocations) would definitely be useful to see if segfaults/crashes reported by users can even be remotely related to the new system or not. If we had this option now, it would be much easier for us to provide support to the users here seeing "OpenGL out of memory" errors.

All that aside, your earlier comments regarding "swapping" all still hold true - Thorsten just confirmed that this is also what "kills" FG for him: viewtopic.php?f=68&t=17114&p=164934#p164933

In other words, I do think that it would be worthwhile to keep this in mind and possibly really come up with a subsystem that monitors FlightGear's RAM usage at configurable intervals of say 1-5 seconds, and dumps all the info to the property tree, where it can be further processed by Nasal scripts or GUI listeners. If it's really swapping that slows down or kills FG for so many people, we obviously need to prevent it - and having access to real time memory usage stats would definitely seem useful then - not just for the random buildings system, but also all other subsystems that may "over-allocate" and run into swap space.

Thus, even just having a boolean "/memory/swap/is-swapping" would be useful, because other subsystems could monitor it using a listener and then adjust their own allocation behavior dynamically.

EDIT: I can handle the Linux implementation of this ...


stuart wrote:The problem is that I'm not sure if we have access to the current real memory (as opposed to addressable space), because we'd want to stop generating buildings before we start swapping to disk.


Here's a first stab at a simple subsystem to monitor FlightGear memory usage on Linux at 5 second intervals, consider it a "proof of concept" prototype now, as this would need to be cleaned up and implemented for Mac/Windows respectively - on Linux it simply works such that it merely fopen()s /proc/pid/smaps and copies two metrics to the property tree:

Code: Select all
diff --git a/src/Main/CMakeLists.txt b/src/Main/CMakeLists.txt
index 2a541e3..44953b1 100644
--- a/src/Main/CMakeLists.txt
+++ b/src/Main/CMakeLists.txt
@@ -20,9 +20,14 @@ set(SOURCES
    main.cxx
    options.cxx
    util.cxx
+   ram_usage.cxx
    ${RESOURCE_FILE}
    )
 
+IF(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
+        list(APPEND SOURCES ram_usage_linux.cxx)
+ENDIF(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
+
 set(HEADERS
    fg_commands.hxx
    fg_init.hxx
@@ -34,8 +39,15 @@ set(HEADERS
    main.hxx
    options.hxx
    util.hxx
+   ram_usage.hxx
    )
 
+IF(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
+        list(APPEND HEADERS ram_usage_linux.hxx)
+ENDIF(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
+
+
+
 get_property(FG_SOURCES GLOBAL PROPERTY FG_SOURCES)
 get_property(FG_HEADERS GLOBAL PROPERTY FG_HEADERS)
 
diff --git a/src/Main/fg_init.cxx b/src/Main/fg_init.cxx
index 651b0d4..3c9d10f 100644
--- a/src/Main/fg_init.cxx
+++ b/src/Main/fg_init.cxx
@@ -116,7 +116,7 @@
 #include "globals.hxx"
 #include "logger.hxx"
 #include "main.hxx"
-
+#include "ram_usage.hxx"
 
 using std::string;
 using namespace boost::algorithm;
@@ -1083,6 +1083,10 @@ bool fgInitSubsystems() {
     ////////////////////////////////////////////////////////////////////
     globals->add_subsystem("properties", new FGProperties);
 
+    ////////////////////////////////////////////////////////////////////
+    // Add the ram usage statistics system
+    ////////////////////////////////////////////////////////////////////
+    globals->add_subsystem("memory-stats", new MemoryUsageStats, SGSubsystemMgr::INIT, 5.00);
 
     ////////////////////////////////////////////////////////////////////
     // Add the performance monitoring system.
diff --git a/src/Main/ram_usage.cxx b/src/Main/ram_usage.cxx
new file mode 100644
index 0000000..1b1e567
--- /dev/null
+++ b/src/Main/ram_usage.cxx
@@ -0,0 +1,22 @@
+#include "ram_usage_linux.hxx"
+
+MemoryUsageStats::MemoryUsageStats() {
+ _mem = new LinuxMemoryInterface(); //FIXME: should be implemented for Win/Mac & Linux
+}
+
+MemoryUsageStats::~MemoryUsageStats() {
+ delete _mem;
+}
+
+void
+MemoryUsageStats::update(double dt) {
+   _mem->update();
+   double swap = _mem->getSwapSize();
+   double total = _mem->getTotalSize();
+   SG_LOG(SG_GENERAL, SG_DEBUG, "Updating Memory Stats:" << total << " kb");
+   fgSetInt("/memory-usage/swap-usage-kb",  swap );
+   fgSetInt("/memory-usage/total-usage-kb", total );
+}
+
+
+
diff --git a/src/Main/ram_usage.hxx b/src/Main/ram_usage.hxx
new file mode 100644
index 0000000..e9febb9
--- /dev/null
+++ b/src/Main/ram_usage.hxx
@@ -0,0 +1,51 @@
+#ifndef __RAM_USAGE
+#define __RAM_USAGE
+
+#include <simgear/timing/timestamp.hxx>
+#include <simgear/structure/subsystem_mgr.hxx>
+
+#include <Main/globals.hxx>
+#include <Main/fg_props.hxx>
+
+#include <string>
+#include <map>
+
+using std::map;
+
+// Linux: /proc/pid/smaps
+// Windows: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682050(v=vs.85).aspx
+
+class MemoryInterface {
+public:
+ MemoryInterface() {}
+ typedef map<const char*, double> RamMap;
+//protected:
+ virtual void update() = 0;
+
+ double getTotalSize() const {return _total_size;}
+ //virtual void   setTotalSize(double t) {_total_size=t;}
+
+ double getSwapSize() const {return _swap_size;}
+ //virtual void   setSwapSize(double s) {_swap_size=s;}
+protected:
+ RamMap _size;
+ std::string _path;
+ std::stringstream _pid;
+
+ double _total_size;
+ double _swap_size;
+};
+
+class MemoryUsageStats : public SGSubsystem
+{
+public:
+  MemoryUsageStats();
+ ~MemoryUsageStats();
+  virtual void update(double);
+protected:
+private:
+  MemoryInterface* _mem;
+};
+
+#endif
+
diff --git a/src/Main/ram_usage_linux.cxx b/src/Main/ram_usage_linux.cxx
new file mode 100644
index 0000000..673e564
--- /dev/null
+++ b/src/Main/ram_usage_linux.cxx
@@ -0,0 +1,49 @@
+// https://gist.github.com/896026/c346c7c8e4a9ab18577b4e6abfca37e358de83c1
+
+#include "ram_usage_linux.hxx"
+
+#include <cstring>
+#include <string>
+
+#include "Main/globals.hxx"
+
+using std::string;
+
+LinuxMemoryInterface::LinuxMemoryInterface() {
+ _pid << getpid();
+ _path = "/proc/"+ _pid.str() +"/smaps";
+}
+
+void
+LinuxMemoryInterface::OpenProcFile() {
+ file = fopen(_path.c_str(),"r" );
+ if (!file) {
+        throw("MemoryTracker:Cannot open /proc/pid/smaps");
+    }
+ SG_LOG(SG_GENERAL, SG_DEBUG, "Opened:"<< _path.c_str() );
+}
+
+LinuxMemoryInterface::~LinuxMemoryInterface() {
+ if (file) fclose(file);
+}
+
+void LinuxMemoryInterface::update() {
+ OpenProcFile();
+ if (!file) throw("MemoryTracker: ProcFile not open");
+
+  _total_size = 0;
+  _swap_size = 0;
+
+  char line[1024];
+  while (fgets(line, sizeof line, file))
+    {
+        char substr[32];
+        int n;
+        if (sscanf(line, "%31[^:]: %d", substr, &n) == 2) {
+          if (strcmp(substr, "Size") == 0)           { _total_size += n; }
+               else    if (strcmp(substr, "Swap") == 0)           { _swap_size += n; }
+    }
+   }
+  fclose(file);
+}
+
diff --git a/src/Main/ram_usage_linux.hxx b/src/Main/ram_usage_linux.hxx
new file mode 100644
index 0000000..2fa2045
--- /dev/null
+++ b/src/Main/ram_usage_linux.hxx
@@ -0,0 +1,22 @@
+#ifndef __RAM_USAGE_LINUX
+#define __RAM_USAGE_LINUX
+
+ #include <sys/types.h>
+ #include <unistd.h>
+
+ #include "ram_usage.hxx"
+
+class LinuxMemoryInterface : public MemoryInterface {
+public:
+ LinuxMemoryInterface();
+~LinuxMemoryInterface();
+ virtual void update();
+private:
+ void OpenProcFile();
+ const char* filename;
+ FILE *file;
+};
+
+
+#endif
+
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Random Buildings

Postby stuart » Fri Aug 24, 2012 11:16 am

Hi Hooray,

I think you should bring this up on the -devel list. At the very least you'll be able to get help adding support for Mac and Windows.

I think it also opens up a larger question of how we do memory management in FG, and whether we should be doing things such as more aggressively freeing up terrain tiles. At one level, removing entire terrain tiles from memory earlier if memory occupancy becomes a concern would be a better management strategy than just stopping generating new buildings.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Random Buildings

Postby Hooray » Fri Aug 24, 2012 4:14 pm

stuart wrote in Fri Aug 24, 2012 11:16 am:I think you should bring this up on the -devel list. At the very least you'll be able to get help adding support for Mac and Windows.

Well, I have meanwhile looked up what's needed - and it seems pretty doable actually. I also added some links to the patch. The question is if this is something that we want to have in the property tree or not. It would obviously be able to publish more metrics and also publish "trends" for FG memory use.

I think it also opens up a larger question of how we do memory management in FG, and whether we should be doing things such as more aggressively freeing up terrain tiles.

This is true, but then again - there really needs to be better memory management strategy employed in FlightGear in general. I mean, smart pointers have been part of simgear long before SGReferenced and long before osg::ref_ptr [1], still there's lots of new stuff added each week not using any smart pointers at all - including my patch by the way ;-)

Your code is an exception in that it uses all the osg::ref_ptr machinery already...

That said, OSG has quite a lot of "clever" machinery to help with memory management, at least with all the rendering-related stuff.
For "problems" like excessive ram usage with random buildings and random trees, there are well-defined "standard" solutions available in OSG - but for many others, there aren't any. So rendering-related issues can be obviously addressed by using what's provided by OSG.

Thus, the issue is real two-fold: some subsystems making excessive usage of RAM, and others leaking lots of memory.

Probably, that would justify introducing a dedicated "memory management subsystem" eventually - i.e. something like a new/delete replacement that uses the boehm/weiser GC to manage resources dynamically, or a custom memory pool implementation using "placement new" for subsystems and other code allocating memory.


Manual memory management in C++ is always extremely tedious and error-prone, especially in non-trivial projects with a long history and lifespan.

Also see:
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

PreviousNext

Return to Scenery

Who is online

Users browsing this forum: No registered users and 5 guests