[Csantucci]

 akioyamamura, on 22 December 2021 - 05:32 AM, said:

I'm trying the "reduce memory usage" feature, and having a minor problem with the ACCELEROMETER. As you can see in the video the accelerometer it's working fine until 3:37 and than he disappear, when it's need to show the positive value. It's happens in every path that I tried and sometimes the negative value disappear too. Deactivating the "reduce memory usage" everything works again. Just to clarified the accelerometer number are highlighted in the printscreen attched.
Tested with 32 bits box checked too, but the problem persists.
Thank you.

Does this occur also with the official Unstable release?

[akioyamamura]

 Csantucci, on 22 December 2021 - 10:47 AM, said:

Does this occur also with the official Unstable release?

I tried the Unstable and had the same problem. As you can see, the Unstable don't have the "reduce memory usage", right?

Attached File(s)

•  Sem título.jpg (118.25K)
  Number of downloads: 0

[cjakeman]

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

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.

 James Ross, on 24 December 2021 - 09:15 AM, said:

Memory usage comes up all the time and, with two recent threads in particular, it is necessary for users to be able to compare numbers across each other, computers, and Open Rails versions.


The measurements are:

• CPU Memory: these all measure memory inside the Open Rails process - including both RAM and page file unless noted otherwise
  • private: private memory cannot be shared with other processes
  • working set: private and shared memory which is currently in RAM
  • private working set: private memory which is currently in RAM
  • managed: all memory used by the .NET runtime (CLR)
  • virtual: virtual memory is everything (private and shared) and is limited to 2GB on 32-bit computers or 4GB on 64-bit computers (when large address aware is enabled)
  
  
• GPU Memory: these all measure memory associated with the graphics card
  • committed: total amount of memory requested by Open Rails
  • dedicated: amount currently in dedicated memory/VRAM (i.e. on the graphics card)
  • shared: amount currently in shared memory (i.e. in normal computer memory)

All these numbers (except managed CPU memory) update every 10 seconds to keep interference low. The GPU Memory numbers may not be available on Windows 7 - it would be useful if anyone who still has Windows 7 could check this.

The changes are in U2021.12.24-1706.

Serana has introduced a bug fix into the Unstable Version so that might perform better than the Testing Version.

James has added memory measures initially into the Unstable Version and, from Friday 14th Jan, into the Testing Version.

After Friday, you can therefore use these changes to compare the Testing Version with the Unstable Version including Serana's fix and discover how much that fix improves things and is there more work to be done.

I have a Pull Request in the Unstable Version that gives us 64-bit operation on a 64-bit OS. I've just blocked that temporarily so the Unstable Version is back to being 32-bit and can be directly compared with the Testing Version.

[cjakeman]

 cjakeman, on 13 January 2022 - 11:19 AM, said:

I have a Pull Request in the Unstable Version that gives us 64-bit operation on a 64-bit OS. I've just blocked that temporarily so the Unstable Version is back to being 32-bit and can be directly compared with the Testing Version.

Does anyone have any results from comparing the 32-bit Unstable Version with the 32-bit Testing Version using James' memory metrics in the HUD (VRAM etc).

• Does Serana's memory fix in the Unstable Version resolve all the memory leaks?
• Are there any left?
• I would expect Unstable and Testing to give different results. Is that the case?

[Eldorado.Railroad]

 cjakeman, on 19 January 2022 - 11:21 AM, said:

Does anyone have any results from comparing the 32-bit Unstable Version with the 32-bit Testing Version using James' memory metrics in the HUD (VRAM etc).

• Does Serana's memory fix in the Unstable Version resolve all the memory leaks?
• Are there any left?
• I would expect Unstable and Testing to give different results. Is that the case?

Please elaborate, what initial version (exact .zip file name) should I download from James' Simple Silver Site that has ALL of these changes to test together?

Thanks,

Steve

[cjakeman]

 Eldorado.Railroad, on 20 January 2022 - 01:46 PM, said:

Please elaborate, what initial version (exact .zip file name) should I download from James' Simple Silver Site that has ALL of these changes to test together?

Thanks for offering to test.

You should be comparing the latest Testing version with the latest Unstable version.

[Eldorado.Railroad]

 cjakeman, on 21 January 2022 - 12:05 AM, said:

You should be comparing the latest Testing version with the latest Unstable version.

Chris,
Sorry, this was not the answer I was looking for!

There have been umpteen builds since this was implemented, and there are also other bugs that have been discovered/produced that are unrelated to this implementation. What I am looking for is the FIRST build where this implementation was deemed stable enough to test on this site:

https://james-ross.c...jects/or/builds

This site is where I have always done any of my testing/compares. A specific .zip file name from the site mentioned above is what I need. The purpose of this is to do a proper regression test! I have an activity on a specific route which is purposely constructed to stress test memory management. If you would like an accurate assessment of the fix, this activity/setup will provide a proper test. Until this test is done, I would not conclude that the fix works as expected/desired.

Thank you for your effort and cooperation,
Steve

[cjakeman]

Hi Steve,

 Eldorado.Railroad, on 21 January 2022 - 08:54 AM, said:

Sorry, this was not the answer I was looking for!

There have been umpteen builds since this was implemented, and there are also other bugs that have been discovered/produced that are unrelated to this implementation. What I am looking for is the FIRST build where this implementation was deemed stable enough to test on this site:

The memory fix was added to the Unstable Version on 14 Jan 22 07:52, which corresponds to 2022-01-14 08-13-53.zip
The memory measurement was added to the Testing Version on 13 Jan 22 22:26 and, as far as I can tell, it was added to the Unstable Version on 27 Dec 21 14:04, which corresponds to 2021-12-27 15-13-24.zip

Hope that helps,

[Eldorado.Railroad]

 cjakeman, on 21 January 2022 - 11:24 AM, said:

The memory fix was added to the Unstable Version on 14 Jan 22 07:52, which corresponds to 2022-01-14 08-13-53.zip
The memory measurement was added to the Testing Version on 13 Jan 22 22:26 and, as far as I can tell, it was added to the Unstable Version on 27 Dec 21 14:04, which corresponds to 2021-12-27 15-13-24.zip

Hi Chris,

The following results were compiled with this version:
2022-01-14 08-13-53.zip

The selected route had paths created for the user train, and AI trains, running in opposite directions. The AI trains followed exactly the same path, for a total of 26 consists, staggered so as to not create problems in the test with timing. The route, Roger's Pass by MLT was used, from Revelstoke to Field. This implies many miles and world tiles. The sim time needed is about 10 hours to complete the test. I cheated a bit by using autopilot and a 5-10 fold sim acceleration to complete these tests in a reasonable amount of time. I may elect to do a "realtime" test if there is sufficient support and reason to do so. Please keep in mind this would require the simulation to run for 10 hours straight! It is a real benefit to do this test in a completely automated fashion.

The 26 consists were as varied as possible so that few, if any, duplicates existed in the shapes/textures etc. This is a very important parameter. I have used this testing procedure for at least 10 years now, still my gold standard.

Please note that these tests were done on a Win 7 (64 bit) machine. The extra debug code for the GPU that James provided recently has been proven to not function in Win 7.

1. The following screen grabs were done with a moving camera, meaning the user train departs Revelstoke towards Field with an encounter of 26 trains en route proceeding in the opposite direction. Please note the values for CPU memory in the debug HUD screen captures. Not much if any memory was managed, initially it is 348 MB, but at the end of the activity, it is a whopping 894 MB.

Start values, MOVING camera
 Start_Moving_U2022.01.14-0807.gif (60.64K)
Number of downloads: 2

End values, MOVING camera
 End_Moving_U2022.01.14-0807.gif (73.52K)
Number of downloads: 2


2. The following screen grabs were done with a static camera, meaning the camera stays in a fixed position on one tile, at Revelstoke. The user train was allowed to depart Revelstoke towards Field, however please note that the camera did not follow with it! The AI trains parade in front of the static camera in the same sequence as the moving test above. When the AI trains reach the end of their path they disappear from the Map window, as expected. While there is "slightly" less memory consumed compared with the moving camera test, please note the starting and ending numbers for "Memory" in the debug HUD screen captures. A huge amount of textures/materials/shapes are not being managed at all.

Start values STATIC camera
 Start_Static_U2022.01.14-0807.gif (71.42K)
Number of downloads: 2

End values STATIC camera
 End_Static_U2022.01.14-0807.gif (102.48K)
Number of downloads: 1

My verdict is that we have not eliminated these memory bugs yet. Unfortunately more work needs to be done.:cry1:

More tests may be possible on request.

Thanks,
Steve

PS: Please acknowledge this post, thanks!

[Serana]

The modifications only impacts GPU VRAM usage.

So, it's normal there is no impact on CPU RAM usage.

The tests must be done on Windows 10 or 11.