[Haran Banjo]

Csantucci, on 12 December 2021 - 12:45 AM, said:

Yes, it works now. Good job!

I also have the same problem with the signals, how is it solved?

[Csantucci]

I'm merging into ORNYMG Cédric's improvements with the ones that were already present there (subject to the selection of the Reduce Memory Usage option).
Doing this I noticed that I had also modified Sweep() this way within Shapes.cs

        public void Sweep()
        {
            foreach (var path in ShapeMarks.Where(kvp => !kvp.Value).Select(kvp => kvp.Key))
            {
                var shape = Shapes[path];
                Shapes.Remove(path);
                if (Viewer.Settings.ReduceMemory)
                {
                    foreach (var lod in shape.LodControls)
                        for (var subObjectIndex = 0; subObjectIndex < lod.DistanceLevels[0].SubObjects.Length; subObjectIndex++)
                            foreach (var prim in lod.DistanceLevels[0].SubObjects[subObjectIndex].ShapePrimitives)
                                prim.VertexBuffer.Dispose();
                    shape = null;
                }
            }
        }

I wonder whether this can be of interest.

[gpz]

As I glanced into the code, these all should actually be IDisposables (the Shape, LodControl, DistanceLevel, Subobject, ShapePrimitive), because the lowest level ShapePrimitive has two disposable members: the VertexBuffer and the Indexbuffer. (Carlo, you might have also needed to dispose the latter: prim.IndexBuffer.Dispose(); )

And the call would be simply

var shape = Shapes[path];
Shapes.Remove(path);
shape.Dispose();

, and it would roll down by the chain.

[Csantucci]

Thanks Peter,
C# does not like shape.Dispose(), because it doesn't find the method. Instead I could add prim.IndexBuffer.Dispose();.

[gpz]

I mentioned the shape.Dispose(), because that would be the "clean" implementation. All of the classes in the chain must implement the IDisposable interface, and all of them implement the Dispose() method, which calls all the member's own Dispose(). The basic thumb-rule is that every class has to implement the IDisposable interface that has at least one IDisposable member.

[Csantucci]

OK, I see.
I have now performed the merge as described here http://www.elvastowe...post__p__279251 , and this is available in ORNYMG rev. 112. In ORNYMG the feature requires the general option Reduce Memory Usage to be checked; the requirement will probably be removed when the feature will become tested enough.

[Csantucci]

A user reports a crash in the Loading screen dispose, because his test route has no loading screen...

[Serana]

Ok, I will add a null-conditional operator to this.

[akioyamamura]

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.

https://youtu.be/VlRMdvr8hus

Attached File(s)

•  OpenRailsLog.txt (59.77K)
  Number of downloads: 2
•  Open Rails 2021-12-21 10-09-51.jpg (397.59K)
  Number of downloads: 0

[Serana]

Csantucci, on 17 December 2021 - 01:23 AM, said:

I'm merging into ORNYMG Cédric's improvements with the ones that were already present there (subject to the selection of the Reduce Memory Usage option).
Doing this I noticed that I had also modified Sweep() this way within Shapes.cs

        public void Sweep()
        {
            foreach (var path in ShapeMarks.Where(kvp => !kvp.Value).Select(kvp => kvp.Key))
            {
                var shape = Shapes[path];
                Shapes.Remove(path);
                if (Viewer.Settings.ReduceMemory)
                {
                    foreach (var lod in shape.LodControls)
                        for (var subObjectIndex = 0; subObjectIndex < lod.DistanceLevels[0].SubObjects.Length; subObjectIndex++)
                            foreach (var prim in lod.DistanceLevels[0].SubObjects[subObjectIndex].ShapePrimitives)
                                prim.VertexBuffer.Dispose();
                    shape = null;
                }
            }
        }

I wonder whether this can be of interest.

This is indeed interesting, I will introduce something similar, but with the refactoring proposed by Peter.

[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