[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

[Eldorado.Railroad]

Csantucci, on 23 January 2022 - 02:02 AM, said:

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.

Carlo,

Thanks for the clarification! I might have missed this option and as I write this I am not sure if that option only exists in your Monogame version. My CPU memory tests that I published are still valid and I stand by them, but as I explained to Cedric above, I used an external GPU monitoring program, that also monitors/logs GPU memory usage and can be analyzed in Excel/Libre Office etc. The preliminary results did not look very promising. I will double check that the "Reduce Memory Space" is enabled, but I hope that the menu options in OR are the same for both versions of Monogame, ORNY and the "official" testing version Chris pointed out to me.

molte gracie,

Steve

[Csantucci]

Steve, the "Reduce memory" option in ORNYMG coincides practically 100% in its effects with Serana's code. So, if Serana's code has effect only on GPU memory, the same is true for the "Reduce memory" option.

Could you tell us which external program you are using to log GPU and CPU memory usage? I'd be interested in using it.

[Serana]

Eldorado.Railroad, on 23 January 2022 - 10:57 AM, said:

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

FR:
Bonjour,
Il n'y a pas de soucis, je ne l'ai pas pris mal. http://www.elvastower.com/forums/public/style_emoticons/default/wink.gif

En fait, je suis d'accord sur le fait qu'il y ait des choses à modifier côté utilisation de la RAM. La question reste encore de trouver ce qui doit être corrigé.

Ca ne va pas être évident à corriger car, en fait, on voit après avoir laisser l'occupation mémoire RAM s'accumuler, quand on déclenche une pause dans le programme (avec le mode debug de Visual Studio) puis qu'on le relance, on retrouve la même occupation mémoire que juste après le chargement de l'activité. Cela signifie que le ramasse-miettes (ou Garbage Collector), le processus qui est censé faire le ménage après la suppression d'une variable, fait son boulot... mais qu'il est saturé. Et ce n'est pas évident à corriger car il faut trouver les bouts de code qui crée des variables et les supprime juste après.

EN:
Hello,

No worry, I didn't take it badly. http://www.elvastower.com/forums/public/style_emoticons/default/wink.gif

In fact, I agree on the fact that there are things to change on the RAM usage side. The question is to find what must be fixed.
It won't be easy because, we can see after having let the RAM usage accumulate, when we pause the program (with the debug mode of Visual Studio) and then restart it, we get the same RAM usage as after the loading of the activity. That means the Garbage Collector, the process that is supposed to clean up the memory after the deletion of a variable, does its job... but it is saturated. And this is not easy to fix because we have to find pieces of code that create variables and delete them just after.

[Eldorado.Railroad]

Tonight I ran a test with a different external tool, TechPowerUP GPU-Z 2.44.0

The results here are for the Static Camera test, as explained here: http://www.elvastowe...post__p__281132

The graph is for both GPU and CPU usage. Please note the extreme left and right of the graph, these are the start and end points of runactivity.exe, hence the abrupt increase and decrease in memory usage.

 Static-Combo-Chart.gif (57.96K)
Number of downloads: 0


Unless proven otherwise, there is a demonstrable increase in both GPU and CPU memory use throughout the activity. It is not clear what memory GPU or CPU is being managed. I could try to redo this test with a version of OR, prior to the GPU memory fix, but I think I would get the same results. The Moving Camera test can be done if requested, it will take longer to do as 1000% acceleration is not really possible for an extended period of time, possibly would yield faulty results.

The raw data used to create this graph is available in a .cvf file on request.

Steve

[Csantucci]

I have performed a comparison test using TechPowerUP GPU-Z 2.44.0 (Steve, thanks for the hint).
I used ORNYMG, because simply by enabling and disabling the "Reduce memory usage" option, it is possible to make comparisons under exactly the same conditions. As stated precedently, what this option does is the same as Serana's PR.
I disabled the Wifi and the Antivirus during the test.
I run the 1641_STmTi_ORTS activity of the freeware Bernina route, from St. Moritz to Ospizio Bernina in autopilot mode, increasing game speed to 225%.
To be sure about the results, I run two tests with the option enabled, and two tests with the option disabled.
My old laptop has a video card with 1 GB VRAM https://www.techpowe...e-gt-120m.c1847 .
Attached you have the .txt files obtained for a couple of run.
As can easily be seen, with the option enabled initial VRAM used is 484 MG, which increases up to 711 around Pontresina, and then reduces very rapldly under 500 MB, terminating at 482 MB.
With the option disabled initial VRAM used is 483 MG, which continues increasing up to near the ceiling of 1 GB (maximum reached is 1021) and terminates at 1008 MB.

So to me the result is clear: ORNYMG "Reduce memory option" and Serana's PR significantly reduce the occupied VRAM. Therefore:
1) I warmly suggest to ORNYMG users to enable this option, and I will set it enabled by default in next ORNYMG release.
2) I suggest to pass Serana's PR from "draft" to "Review required" and to positively review and merge it.

Are there other VRAM memory leaks? I don't know, but if there are, they are probably small.
Are there CPU RAM memory usage problems? Quite probably yes; as written somewhere else by more than a person, it seems that the GC is a bit shy and does not do its job often enough; but this is not what the here tested OR code is about.

What I am wondering is only why there don't seem to be graphic malfunctions, even when the VRAM tops its max value.

 GPU-Z Sensor Log_reducememory.txt (5.78K)
Number of downloads: 0
 GPU-Z Sensor Log.txt (5.74K)
Number of downloads: 0

 OpenRailsLog_reducememory.txt (16.35K)
Number of downloads: 1