[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.

[R H Steele]

Just caught up on this interesting thread, interesting work being done, thanks...would appear to be an important issue to get to the bottom of.

[Csantucci]

Serana, on 10 December 2021 - 12:14 PM, said:

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.

I now remember that I had the same experience with my ORNYMG option "Reduce memory usage". I believe neither the signal light textures (or materials) are managed.

[Serana]

I have added this draft pull request : https://github.com/o...nrails/pull/545
If you see missing textures, please tell me in the pull request where they are used (for example, in the cabview, etc.) because that means that these textures are not yet marked by the simulator and are wrongly removed from GPU RAM.

To give some idea about what gain I had with this code, for a quite dense route, after a run from Chelles (near Paris) to Champagne Ardenne TGV (near Reims) so about 120 km, I went from 3 GB of VRAM usage to 1.9 GB.
It seems to still be rising slowly so there may still be another leak somewhere. Maybe I have to look on the shapes' side.

It also had a weird side effect : changing cab (with a 3D cab on both side) from front of the train to the rear was much quicker than before: from several seconds to nearly instant.

[cjakeman]

Serana, on 10 December 2021 - 02:24 PM, said:

I have added this draft pull request : https://github.com/o...nrails/pull/545

It's great that you're pursuing this, Cedric

[Csantucci]

Cédric,
I've tested the Unstable release, but I am getting the problem I mentioned above, see picture
 DarkSignals.jpg (263.31K)
Number of downloads: 7
The signals are dark.
This occurs with a high speed route, using a path where at the beginning there are traditional light signals, in the central part there are ERTMS signals, and in the end part there are again traditional light signals. When the train enters this last part, the signal lights don't appear, while this does not occur with the other official OR versions (testing and stable).

I have also a question: you are mentioning data about memory occupation of the VRAM. Are you really mentioning VRAM, or is it DRAM (which is the one shown in the Debug Info HUD)?