In-built large scale memory management

About Icarus Forums Icarus Scene Engine Memory Management In-built large scale memory management

Tagged: ,

This topic contains 0 replies, has 1 voice, and was last updated by  admin 1 year, 5 months ago.

  • Author
  • #399


    How Icarus 4.0 manages memory issues in .NET & OpenGL, related file structures, native classes for assisting and performance optimisation:

    First, what are the memory issues, because .NET automates memory management?

    Well, yes, but ISE uses OpenGL, OpenAL, FFmpeg etc.. etc.. which are all external native libraries, and there are also caps inside .NET when individual objects also get big enough e.g. a single object array of byte[] > 64Mb in size may have problems being allocated from time to time once the project contains enough of a volume of assets.

    .NET issues, 32 bit & 64 bit.

    Firstly, older .NET was capped at having a 2Gb memory limit, so ISE 4.0 targets .NET 4.5 onwards where this limit is removed.

    32-bit apps have a 4Gb max limit anyway, so ISE 4.0 is built for native 64-bit support, and apps built with ISE 4.0 should be targeted at 64-bit primarily. The default build is AnyCPU, with “prefer 32 bit” should be disabled to prefer 64 bit execution.

    If your 64-bit-targetted app is also intended for 32-bit execution, texture memory will be the predominant memory consumer. As such, command line (and internal) parameters can be set to automatically filter out and not load the larger mipmaps. e.g. MIPMAP1 will eliminate all mipmapping level 0 textures (the largest mipmap), except for fonts. MIPMAP2 will eliminate both level 0 and level 1 mipmaps, and so on.

    XML-Related issues:

    XML-based file formats can’t cope with large embedded binary data, the internal .NET XML reader starts having memory allocation issues, plus the XML becomes impractical to edit in Notepad ++ or Textpad (etc..).

    ISE uses a secondary binary store associated with the XML file for storage of large data objects (e.g. textures, a 4096×4096 texture with 12 mipmapping levels can be upwards of 128Mb of data! A 3D texture that has e.g. 128 depth layers can be equally large.

    Byte[] related issues and large memory streams.

    Large byte[] allocations may fail from time to time, and will also heavily fragment the .NET memory manager, so to combat these, ISE uses two classes, a Memory Tributary and a Big Array:


    Memory Tributary:

    This is a large Stream object that allows large chunks of memory to be accessed as a single stream, by loading multiple smaller byte[] allocations in a contiguous memory stream

    Big Array

    This is a similar concept, but implemented as a single accessible “array”.


    Both of these use a smaller predefined byte[] chunks that are the same chunk size, and quickly discarded after use. The size of chunk is controlled by the Global. memory allocation values, and currently changes depending on the .underlying platform (Mono has a much poorer memory manager, smaller chunk sizes are more successful in a Mono environment), so that memory freed up by one can use the other. There are default values for these, but once Engine.Initialise() has been called, you may override these values and they become “the new normal”.

    OpenGL-related issues:

    Uploading large textures and geometry can become a problem. Since ISE uses the Big Arrays to load data, the VAO-builder in ISE 4.0 uses this same configuration to upload geometry to OpenGL in manageable portions, again following the same chunk size to optimise memory management & performance, especially since chunks need to be Pinned to transmit data to OpenGL, so an already-pinned chunk that has been used elsewhere and is now unused can be recycled and no need to re-pin.

    OpenAL-related issues.

    The Audio Manager in ISE streams in data in user-defined chunk sizes that vary depending on use case by default anyway, and playback is managed in blocks as a result.

    Mesh Optimisation

    EntityMeshes are now element-based in ISE 4.0. The Asset Manager, and the underlying EntityMesh class, now has an OptimiseMesh function which will scan any existing EntityMesh and eliminate any shared vertices (with matching texture and normal coordinated). Typically this can result in a 10% performance boost over older ISE 3.0 meshes, on top of greatly reduced memory requirements for the geometry.

    • This topic was modified 1 year, 5 months ago by  admin.
    • This topic was modified 1 year, 5 months ago by  admin.
    • This topic was modified 1 year, 5 months ago by  admin.
    • This topic was modified 1 year, 5 months ago by  admin.
    • This topic was modified 1 year, 5 months ago by  admin.
    • This topic was modified 1 year, 5 months ago by  admin.

You must be logged in to reply to this topic.

Comments are closed.