[alteo80]

hello, I regularly use your version of openrail, today, during an activity loaded with traffic and static equipment, on a French road at the lge v4, I noticed that the video memory is not discharged, and at the end of the activity which lasts 30 min, I reached 7190 mo of use of the video memory. letting the game continue the occupation of the memory continues to increase slowly. the graphics card has 8 gb of ram embeded and the system 16 gb ... tests carried out only on the latest version 108.2. thanks

[engmod]

Hi Alte,

I have just tested RMD_west and tested with GPUz and I find that GPUz reports "system memory used" rather than graphics card memory used.
I also used the extended HUD in 108.2 to see what memory usage it reports, but I unsure what memory it reports.

How are you measuring memory used?

[alteo80]

engmod, on 05 November 2021 - 07:12 PM, said:

Hi Alte,

I have just tested RMD_west and tested with GPUz and I find that GPUz reports "system memory used" rather than graphics card memory used.
I also used the extended HUD in 108.2 to see what memory usage it reports, but I unsure what memory it reports.

How are you measuring memory used?

hello, to measure, I use two soft, to be sure, msi afterburner and xtremetunerplus which is used by the manufacturer of my video card. the results are identical, it looks like a memory leak, it seems to me that it was reported in last April on this forum http://www.elvastowe...es-more-memory/ the more we advance in the versions the more the fps deteriorate ... a memory leak is also present ... am I really the only one?

[engmod]

I have just run an activity from Mullan Pass.
Using the extended HUD and the last screen "debug"
I started with 420MB of gpu memory and ended 1.5 hours later with 1361MB of memory used.

Attached is the OR log and a screen shot at the end of the activity.

Attached File(s)

•  memory_usage_Mullan_1.5Hour.jpg (1.83MB)
  Number of downloads: 12
•  CokeCanyon 2021-11-09 19.00.49.txt (32.61K)
  Number of downloads: 3

[alteo80]

engmod, on 09 November 2021 - 12:35 AM, said:

I have just run an activity from Mullan Pass.
Using the extended HUD and the last screen "debug"
I started with 420MB of gpu memory and ended 1.5 hours later with 1361MB of memory used.

Attached is the OR log and a screen shot at the end of the activity.

hello, and thank you for your example, I have similar results, the American roads are generally much lighter than the European roads, and load less the video memory, the traffic too ... but the observation is there, the game does not restore no memory, it is very clear, memory leak, thank you for the interest in the subject.

[Csantucci]

I have performed some tests yesterday. First I compared the official OR testing version (which is 32 bit) with ORNYMG with the 32 bit option checked. I got very similar results, and memory values growing at beginning, but then oscillating around a more or less stable value.
I then run ORNYMG at 64 bit, and saw memory growing much more. Memory usage is also higher at the beginning of the game.
I then introduced a garbage collection every two minutes, but nothing changed.
Strangely I noticed that, in two occasions, after starting another app while leaving OR in run state (no pause) and after few time moving again the OR window on the foreground, memory was lowered by some humdreds of MB!
At the moment I won't investigate further. I hope that in reasonable time 64 bit will be available also in the OR official version, and at that moment someone capable will solve this.
In the meantime I can only recommend what I recommended also some time ago: if there is no real need to go beyond the 4MB of RAM because the route or the activity is very heavy, it's better to run 32 bit. You use much less memory and probably also run faster.

[alteo80]

hello, and thank you for taking the time to watch and test carlo. we will wait with option 64 unchecked :). the problem is reported. Thank you all. AND GOOD RAIL :)

[engmod]

I have a better one.

3052MB for a 7 hour run on the ruel sub

Attached File(s)

•  HEAVY_WINTER_WESTBOUND 2021-11-12 21.36.37.jpg (2.14MB)
  Number of downloads: 15

[Serana]

GPU memory is generally used by textures. Do you think this memory "leak" is due to textures remaining in VRAM?

On StackOverflow, I have read that textures loaded manually are not removed from VRAM automatically if we don't use the content manager of XNA/MonoGame.
We have to call the Dispose function manually and I don't think we are currently calling this function. (See https://stackoverflow.com/a/48777516)

Perhaps we should call this function from the Sweep function of the SharedTextureManager.

[Serana]

About the main RAM, I did a test session to see what's happening. My results are the following:
- For managed memory (the one that is monitored directly by the application and that is garbage collected): the quantity is more or less constant.
- For unmanaged memory, we have indeed a memory leak: at the start of the session, I had 600MB occupied (300MB managed). At the end, I had 1200MB occupied (300MB managed).

So, it seems that we have some parts of the code using unmanaged memory and we are not cleaning up the memory properly.

[Eldorado.Railroad]

Please try this:

 9 Square Game (Outline).jpg (19.47K)
Number of downloads: 2

Pay close attention to the numbering of the squares. The purpose of this experiment is to move the camera between various squares. The squares represent the tiles in OR. The coordinates of the tile are given in the extended F5 debug HUD.

First) When your camera view, be it inside an engine, etc is on tile #5, and STAYS on tile #5, and you have trains of different types (this means NO repeat shapes and textures) passing back and forth, OR does NOT dispose any items, be it in system or video memory. If you select CAMERA #8 in OR and travel to an adjacent tile from tile #5 (this means tiles # 1,2,3,4,6,7,8,9), OR used to dump a whole bunch of things from memory, especially train data, like shapes and textures. I doubt that terrain data (shapes and textures, etc) on that terrain, houses, fences, trees etc, would be dumped, especially if you have a viewing range way beyond 2000 meters. The saving grace is that often terrain data (shapes and textures, etc) is reused across many tiles, so they do not have to be reloaded, nor will they occupy MORE memory.

Second) When your camera view is with a camera that is traveling, eg:an engine, and you are in tile #5, things used to get dumped from system and video memory as soon as it moves to an adjacent tile (# 1,2,3,4,6,7,8,9).

I would suggest that as an experiment to limit your viewing range to 2000 meters at runtime. Then test the above scenarios, paying close attention to the F5 debug HUD. The fancy graphs at the bottom will show you when things are loaded and unloaded.

If nothing ever gets dumped it means that memory management is broken. But as indicated above there are two scenarios which would be proof. I believe that that the XNA version 1.3x has the expected behavior. I have not looked at more recent Monogame versions.

This is not a new issue. Some 10 years ago it was a struggle to get this problem to be recognized as such. Users that stress test (I include myself) bring this problem back to the surface when noticed. The availability of many GB of RAM memory and 64 bit executables cannot hide poor resource management. As shapes/textures become more numerous and detailed "unlimited" resources will evaporate. If you are using models built for MSTS, from 20 years ago, along with sparsely populated tiles, the Monogame version of OR will "hide" the lack of resource management and perform very well. This is however the end of 2021, and we might very well be forced to take a second look as to how resources are managed.


Hope this helps,
Steve

[cjakeman]

Serana, on 09 December 2021 - 01:34 AM, said:

About the main RAM, I did a test session to see what's happening.

Well done, Cedric.

Was this 32-bit or 64-bit? Official OR or OR_NewYear_MG?

[Serana]

I am using the official version (so 32-bit).

[alteo80]

Serana, on 09 December 2021 - 12:01 PM, said:

I am using the official version (so 32-bit).

hello, finally we get there xd,

[Serana]

Serana, on 08 December 2021 - 02:11 PM, said:

GPU memory is generally used by textures. Do you think this memory "leak" is due to textures remaining in VRAM?

On StackOverflow, I have read that textures loaded manually are not removed from VRAM automatically if we don't use the content manager of XNA/MonoGame.
We have to call the Dispose function manually and I don't think we are currently calling this function. (See https://stackoverflow.com/a/48777516)

Perhaps we should call this function from the Sweep function of the SharedTextureManager.

To continue about this subject: I tried to add the Dispose function in the Sweep function... and when I tested a 3D cab, textures were disappearing.
At first, I thought it was a bug and that I shouldn't use the Dispose function in this function... until I saw that textures were not marked in the 3D cab viewer...

OK, so I have to go through the different renderers in order to see if all textures are marked properly before sweeping.