[James Ross]

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. Unfortunately, we have only had very limited information available in-game for this purpose.

Windows actually provides a lot more detail than we've been showing - including some detail for GPU memory. Some or all of these numbers will appear in other tools (Task Manager, Process Explorer, etc.) but they are not always labelled the same, and different tools may promote different measurements as the "best" one for comparison.

I am working to add more of the Windows measurements directly into Open Rails, so that we can all compare numbers with consistent labels and meaning and without needed any external tools. You can see them all in the screenshot below:

https://james-ross.co.uk/temp/Open Rails 2021-12-24 16-46-20.png

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.

[Genma Saotome]

I switched to the untested version so I could look at this new feature... program updated. When the launch window opened none of the pull downs on the left side of the window were functional. No log produced, no idea what's going on. Will wait for another version to update.

[James Ross]

Genma Saotome, on 24 December 2021 - 10:46 AM, said:

I switched to the untested version so I could look at this new feature... program updated. When the launch window opened none of the pull downs on the left side of the window were functional. No log produced, no idea what's going on. Will wait for another version to update.

If you are referring to the selection dropdowns in the menu, you have an unrelated problem. This change only applies to the in-game HUD DEBUG page.

[cjakeman]

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

• 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)

Just what we need to compare apples with apples and oranges with oranges.

I can't help thinking that the definitions need a Venn diagram to keep it all straight :-)

[Eldorado.Railroad]

Win 7 - 64 test, failed for GPU reporting in the HUD.




Additionally from the OpenRailsLog.txt

Warning: System.InvalidOperationException: Category does not exist.
   at System.Diagnostics.PerformanceCounterLib.GetCategorySample(String machine, String category)
   at System.Diagnostics.PerformanceCounterCategory.GetCounterInstances(String categoryName, String machineName)
   at System.Diagnostics.PerformanceCounterCategory.GetInstanceNames()
   at Orts.Viewer3D.Popups.HUDWindow..ctor(WindowManager owner) in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Popups\HUDWindow.cs:line 161
   at Orts.Viewer3D.Viewer.Initialize() in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Viewer.cs:line 470
   at Orts.Viewer3D.Viewer..ctor(Simulator simulator, Game game) in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Viewer.cs:line 350
   at Orts.Viewer3D.Processes.GameStateRunActivity.Start(UserSettings settings, String acttype, String[] args) in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Processes\GameStateRunActivity.cs:line 331
   at Orts.Viewer3D.Processes.GameStateRunActivity.<>c__DisplayClass36_0.<Load>b__3() in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Processes\GameStateRunActivity.cs:line 175
   at Orts.Viewer3D.Processes.GameStateRunActivity.Load() in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Processes\GameStateRunActivity.cs:line 216
   at Orts.Viewer3D.Processes.LoaderProcess.Load() in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Processes\LoaderProcess.cs:line 161
   at Orts.Viewer3D.Processes.LoaderProcess.DoLoad() in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Processes\LoaderProcess.cs:line 140
   at Orts.Viewer3D.Processes.LoaderProcess.LoaderThread() in C:\Jenkins\jobs\Open Rails Unstable\workspace\Source\RunActivity\Viewer3D\Processes\LoaderProcess.cs:line 111
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()


Warning: Unable to access Windows GPU Process Memory performance counters. This may be resolved by following the instructions at http://support.microsoft.com/kb/300956

The link,
http://support.microsoft.com/kb/300956

Applies to: Windows 10 - all editions, Windows Server 2012 R2

I would not like to "bork" my install by doing the rather long and possibly error prone fix. I hope this is not the thin edge of the wedge to kill off OR in Win 7 (32 or 64)? Can you offer a choice at runtime (through menu.exe) to use the "other/older" HUD should this more elaborate display not work across all Windows versions reliably? Killing old code that works for something that may not, might not achieve the aims to ultimately resolve the memory leaks that OR currently has.

In your O/P your display is an integrated "GPU" in your laptop. I would like to see the results from other users, Win 7-10-11, using a separate GPU like I am using. This might yield different results for the diagnostic display, perhaps similar to my results.

Happy Holidays,

Steve

[Eldorado.Railroad]

cjakeman, on 24 December 2021 - 02:21 PM, said:

I can't help thinking that the definitions need a Venn diagram to keep it all straight :-)

However quaint and simple a Venn diagram might be, I see OR's ongoing memory conundrums more in the realm of the Quine-McCluskey algorithm. :ko2:


Happy Holidays,

Steve

[James Ross]

cjakeman, on 24 December 2021 - 02:21 PM, said:

I can't help thinking that the definitions need a Venn diagram to keep it all straight :-)

Here's an approximate sketch of how these numbers relate to each other:

https://james-ross.co.uk/temp/orts_165.png

Please note that things have been simplified, and the GPU local/non-local memory is roughly the same as the CPU memory's working set vs page file.

[James Ross]

Eldorado.Railroad, on 24 December 2021 - 03:12 PM, said:

Win 7 - 64 test, failed for GPU reporting in the HUD.

Thanks for the test - I did suspect that the GPU information would be Windows 10+ only. Everything else seems to be working in your screenshot, so that's good.

Eldorado.Railroad, on 24 December 2021 - 03:12 PM, said:

The link,
http://support.microsoft.com/kb/300956

Applies to: Windows 10 - all editions, Windows Server 2012 R2

I would not like to "bork" my install by doing the rather long and possibly error prone fix. I hope this is not the thin edge of the wedge to kill off OR in Win 7 (32 or 64)?

This has nothing to do with what Windows versions we support, but about which Windows versions support GPU data. The code is specifically written to work with what information is available and (apart from the log message) ignore what is not available.

I will update the error message, since the instructions are unlikely to help in this case.

Eldorado.Railroad, on 24 December 2021 - 03:12 PM, said:

Can you offer a choice at runtime (through menu.exe) to use the "other/older" HUD should this more elaborate display not work across all Windows versions reliably? Killing old code that works for something that may not, might not achieve the aims to ultimately resolve the memory leaks that OR currently has.

There is no need to offer a choice, because the changes have only added new information - no information that was previously visible has disappeared!

Eldorado.Railroad, on 24 December 2021 - 03:12 PM, said:

In your O/P your display is an integrated "GPU" in your laptop. I would like to see the results from other users, Win 7-10-11, using a separate GPU like I am using. This might yield different results for the diagnostic display, perhaps similar to my results.

My laptop is running Windows 11 with integrated graphics; here's a picture from my desktop running Windows 10 with its dedicated graphics card:

https://james-ross.co.uk/temp/Open Rails 2021-12-24 23-49-42.png

[cjakeman]

James Ross, on 24 December 2021 - 03:40 PM, said:

Here's an approximate sketch of how these numbers relate to each other:

Thanks, James.

[Eldorado.Railroad]

James Ross, on 24 December 2021 - 04:25 PM, said:

This has nothing to do with what Windows versions we support, but about which Windows versions support GPU data. The code is specifically written to work with what information is available and (apart from the log message) ignore what is not available.

I will update the error message, since the instructions are unlikely to help in this case.

There is no need to offer a choice, because the changes have only added new information - no information that was previously visible has disappeared!

Thank you for your response James. May I suggest that a simple conditional be added, where the case being that the O/S does not support/provide the GPU information you have coded, that line in the debug HUD is not displayed at all. There is already a plethora of information in the debug HUD, at least what is displayed should be relevant. Seeing a bunch of "0" entries might be confusing to users. Alternately, a message in the debug HUD for that line should be "Not Supported for you O/S" or similar.

Thank you for your effort and prompt response,
Steve