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

[cjakeman]

Eldorado.Railroad, on 21 January 2022 - 09:07 PM, said:

PS: Please acknowledge this post, thanks!

Thanks for doing this, Steve

[Eldorado.Railroad]

Serana, on 21 January 2022 - 09:35 PM, said:

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.

Hi,

Can you please be VERY clear as to what you mean here? James created some extra code to clarify on the F5 HUD, the use of GPU and CPU memory. I am already aware that the F5 HUD will NOT display the GPU memory usage because the required support for those functions are only readily supported in "some" versions of Windows 10 and most likely all versions of Windows 11. I was the one who tested the F5 HUD display code on Win7-64 and found that it is not supported.

What is not clear in what you stated above is whether your code changes, not what is displayed in the F5 HUD, are restricted to Win 10-11 ONLY. From what I understand the housekeeping code you have fixed/added is for the GPU memory and has no direct extension to what is displayed in the F5 HUD, James is the one who supplied that. If it is the case that this fix is ONLY valid in Win 10-11, then this thread is misleading. I have re-read this thread, and there is no indication that I can see, except for the F5 HUD code that James wrote, that the fix you supplied is only for Win 10-11. As of this writing Win 7 (64-32) is still supported until further notice. If this fix only applies to Win 10-11 then it is not in keeping with the current OS targets for OR. I would explicitly communicate to our users that this fix is only possibly effective in Win 10-11 and nothing else.

Otherwise, if your code is workable in all currently supported OS in OR, should I assume that the GPU memory is being managed differently without proof in the F5 HUD?

Please clarify what you mean, thanks,

Steve

[Serana]

Eldorado.Railroad, on 22 January 2022 - 07:54 PM, said:

Hi,

Can you please be VERY clear as to what you mean here? James created some extra code to clarify on the F5 HUD, the use of GPU and CPU memory. I am already aware that the F5 HUD will NOT display the GPU memory usage because the required support for those functions are only readily supported in "some" versions of Windows 10 and most likely all versions of Windows 11. I was the one who tested the F5 HUD display code on Win7-64 and found that it is not supported.

What is not clear in what you stated above is whether your code changes, not what is displayed in the F5 HUD, are restricted to Win 10-11 ONLY. From what I understand the housekeeping code you have fixed/added is for the GPU memory and has no direct extension to what is displayed in the F5 HUD, James is the one who supplied that. If it is the case that this fix is ONLY valid in Win 10-11, then this thread is misleading. I have re-read this thread, and there is no indication that I can see, except for the F5 HUD code that James wrote, that the fix you supplied is only for Win 10-11. As of this writing Win 7 (64-32) is still supported until further notice. If this fix only applies to Win 10-11 then it is not in keeping with the current OS targets for OR. I would explicitly communicate to our users that this fix is only possibly effective in Win 10-11 and nothing else.

Otherwise, if your code is workable in all currently supported OS in OR, should I assume that the GPU memory is being managed differently without proof in the F5 HUD?

Please clarify what you mean, thanks,

Steve

Hi,

Please also read what Chris asked for.

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?

Chris was asking if my fixes improved the situation and if there is still improvements to be made.
I was saying that my fixes should only improve GPU VRAM usage (for any OS by the way) and that your tests doesn't reveal anything different than before (that's normal, no modifications that impact CPU RAM usage were made).
You don't have access to the GPU VRAM usage statistic (since it's not supported on Windows 7), so it's normal you don't see anything different.

[Csantucci]

Steve,
Serana's fix (which is what is also within the "Reduce Memory Space" option of ORNYMG) iseffective also in Win7 and all versions of Win10. Simply, you don't get a numerical value in the HUD displaying that.

[Eldorado.Railroad]

Serana, on 22 January 2022 - 08:47 PM, said:

Chris was asking if my fixes improved the situation and if there is still improvements to be made.
I was saying that my fixes should only improve GPU VRAM usage (for any OS by the way) and that your tests doesn't reveal anything different than before (that's normal, no modifications that impact CPU RAM usage were made).
You don't have access to the GPU VRAM usage statistic (since it's not supported on Windows 7), so it's normal you don't see anything different.

Cher collègue Cédric,

Je ne veux pas déclencher une guerre sémantique ici. Si cela s'est déjà produit, c'est mon erreur de ne pas comprendre pleinement que le correctif logiciel que vous avez fourni était destiné au GPU et au GPU uniquement. Ce que j'essayais de faire avec mon test, c'était d'afficher que la fuite de mémoire existe pour le côté CPU. J'espère que c'est très clair, même si personne dans notre équipe ne l'a encore reconnu.

Carlo a précisé que le correctif logiciel que vous avez fourni devrait fonctionner en arrière-plan, même si les résultats ne seront pas affichés dans le F5 HUD. C'est le cas pour Win 7. Je l'ai compris depuis le début.

Même si le titre original de ce fil est "memory using monogame or", il semble que l'accent ait été mis uniquement sur le GPU. C'est une situation lamentable mais je comprends que votre effort visait à résoudre un problème, celui de l'utilisation de la mémoire GPU uniquement. Nous avons tous des limites de temps et de compréhension pour corriger les bogues logiciels. Je n'essaie pas de dénigrer vos efforts ici. Désolé si cela ressemble à une critique, ce n'était pas mon intention.

Hier soir, j'ai décidé d'utiliser un utilitaire logiciel externe pour surveiller l'utilisation de la mémoire GPU. Les résultats du correctif logiciel ne semblent pas prometteurs. Les résultats sont placés dans un fichier .cvf et peuvent être analysés dans Excel/Libre Office etc.

Je peux refaire les mêmes tests que j'ai faits et qui ont été affichés/publiés au-dessus de la fuite de mémoire CPU, mais en mettant l'accent sur les fuites de mémoire GPU. Bien que nous aimerions nous fier exclusivement aux résultats affichés dans le HUD F5, je préfère vérifier les résultats par rapport à des programmes externes qui existent / sont mis à jour depuis des décennies.

Carlo a fait allusion au fait que dans sa version de Monogame, il y a un élément dans le menu appelé "Reduce Memory Space" qui doit être défini. Je pense que j'ai peut-être raté cette option. Je vérifierai que l'option est en place pour tout autre test.

En terminant, désolé pour le malentendu. Ce n'était pas intentionnel. J'espère que nous pourrons néanmoins continuer à travailler ensemble.

a votre service,

Steve