K2 Memory Usage

From HoNwiki

(Redirected from 3GB Boot Flag)
Jump to: navigation, search

K2's memory usage has been a heated topic on the General Discussion forums. This article's goal is to clarify how HoN uses ram, what that means as far as crashes are concerned, and things you can do if you are having problems with HoN crashing due to memory allocation errors.

This is a complicated technical explanation of what happens for those that are curious. If you want to know the explanation and just want work around, skip to the Workarounds section.

Contents

Terms

  • Physical System RAM (RAM): This refers to how much RAM physically installed in your computer
  • Video RAM (VRAM): The RAM on your graphics card.
  • Address: The number associated with each byte so that your computer can find it.
  • Physical address: The address where the memory is physically stored on the computer, be it the RAM modules or pagefile on the hard dirve.
  • Address bit length: How many bits (binary digits) are used to store the addresses. These are written in hexadecimal (base 16; 0-F) to save room and for legibility. A 32-bit number, for example, can hold up to 2^32-1 = 4,294,967,295 = 0xffffffff. When each number is used as an address which each stores one byte (8 bits) of information, the maximum amount of memory that can be addressed is therefore 4GiB. A 64 bit number, on the other hand can hold 2^64-1 = 0xffffffff ffffffff, which is much much bigger. That's larger than all the atoms in the galaxy. This is why 64 bit operating systems and programs don't suffer from the 4GiB limitation.
  • Virtual address space (VAS): Applications don't interact with the physical memory locations directly. Instead, each application is given its own 32 or 64 bit virtual range of addresses (depending on if the application is 32 or 64 bit). This virtual memory then has the executable loaded at the start, and the accessible operating system features, such as directx and the windows api, are mapped to the VAS in (usually) 4KiB chunks called pages. By default, Windows reserves 2GiB out of the possible 4GiB virtual address space per application for its own use. This can be tweaked to allow more ram usage by the application as discussed later.
  • Page table: A structure used by the operating system to relate physical memory space to virtual address space. Because virtual memory addresses don't correspond to physical addresses, some of the virtual memory addresses can actually correspond to files on the hard drive known as swap files or swap space. This makes it so that the operating system can keep track of more memory than can actually be stored in 32 bit addresses. Pages can map physical memory or files multiple times from many different physical sources.
  • Virtual addresses: These are what the application actually sees and appear the same to the application even if the memory is actually stored in different locations. For 32 bit applications, even on 64 bit operating systems, there is a maximum of 4GiB addressable memory due to the 32 binary digit length as with physical addresses. However, 64 bit windows allows the application to address the entire 4GiB, rather than limiting it to 2GiB.
  • Kernel space: The part of the virtual memory reserved for the operating system.
  • User space (aka userland): The part of the virtual memory for application use.
  • Memory Mapped Input/Output (MMIO): The mapping of non-RAM devices to virtual memory spaces. This allows hardware, such as graphics cards, to map their storage to memory addresses for the application to see.
  • Texture: The image that is drawn on 3D objects when rendering.
  • Pixel: A pixel is a single block on the output image. Pixel shaders operate on a per-pixel basis to calculate what the color should be.
  • Texel: A "texture pixel" on an object.
  • MIP map: A set of texture resolutions from the main texture at full, 1/2th, 1/4th, 1/8th, etc resolutions down to 1x1 textures. The mipmap uses 4/3 times the memory the texture file would consume on its own. Mipmaps are essential for quality and performance reasons and are a perfect example of why using more RAM can have significant performance enhancements. The reason for mipmaps will be explained later.

For a longer (and more visual) explanation, see the Wikipedia pages: Memory Address, Virtual Memory, Page Table, Memory-Mapped I/O, and Mipmap.

Exclusive Mode

Exclusive Mode is a Direct3D 9 (d3d9) concept closely tied to the way that drivers work in pre-Vista Windows.

Drivers in Windows XP

In Windows XP drivers ran in kernel space, each driver had one process, and that process could be accessed by multiple userland processes. Direct3D 9 runs like a driver. Because kernel space is also limited to 2GiB, there needed to be a way for directx to free up memory as 5 full screen applications each wanting to use, say, all 512MiB of graphics ram on a 512MiB graphics card (which is mapped to the virtual address space) is a perfectly valid thing to do. This is where exclusive mode comes in. Exclusive mode, as far as the graphics card is concerned, allows full screen applications to lock the entire 512MiB of video ram for nothing but themselves. To change between applications, all memory on the gpu is flushed (cleared). Then, the application gaining focus receives control of the video ram and reloads its textures. This means that d3d9 doesn't have the impossible task of managing 2.5GiB of address space with a limit of 2GiB.

Drivers in Windows Vista and Above

After Windows XP, Microsoft decided to completely change the way drivers work. In Vista/7, drivers are no longer single processes, but separate processes tied together with each application. This removes the limitation that Exclusive Mode worked around in XP. However, this also means that d3d9 also runs in userland along with the application. D3d9 had been out for a long time and the way it works is set in stone. This means that the application and d3d9 still keep separate copies of graphics resources (the largest of which are mipmaps, but this applies to everything). The really bad news is that because d3d9 and the application are both in userland, now, available userland addresses get used at twice the rate as in XP! Direct3D 10/11 and OpenGL do not suffer from this new limitation because Direct3D 10/11 were designed around it and OpenGL implementations are maintained by the graphics card manufacturers and are updated often.

Why keep copies of video resources in RAM?

As explained above, exclusive mode requires the textures to be available in case the video ram is flushed. This is also required if the video drivers crash. So, why not reload from the hard drive? That would cause big lag spikes each time a texture needs to be loaded.

Mipmaps

Mipmaps are what the render actually uses to determine the color of a pixel. With antialiasing off, each pixel needs to find a texel in a one pixel area. If more than one texel is found, the renderer must arbitrarily choose which value to use. The result is an aliased image (moire effect). To keep this from happening, the render needs to read from a mipmap dimension less than or equal to the area taken up by the object. The result is a pre-anti-aliased rendering and a massive performance boost over averaging the nearby texels on the fly when rendering.

This means generating mipmaps for each texture. To reduce the footprint on the hard drive, and reduce the amount of data needing to be read from the hard drive, mipmaps are generated when the texture is loading. If a 1024x1024 texture is loaded, then 512x512, 256x256, 128x128, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2, and 1x1 textures must be generated. When loading into a game, this cpu usage is fine. However, it would raise the cpu requirements to play without lag if generated on the fly. It would also cause lag from hard drive access and temporarily leave places with missing textures. If the ram limitation becomes too big of a problem if more and more textures become actively, the mipmaps can be stored in cache files and read from the smallest up in order to at least provide some texture while the larger sizes are loaded. However, this behavior would only be done as an absolute necessity if the address space had been completely exhausted (replacing a less frequently used texture in RAM). This would be nice, if necessary, to store textures from heroes in previous games. However, there are still easier workarounds, such as increasing the size of userland (see Workarounds). It would also feel a lot like pagefile usage to people with low amounts of physical ram and would offer little performance gain. It could be used to give HoN a small memory footprint, but that would create a lot of disk usage, causing lag. This is mainly a problem for games like HoN or Savage 2 RTS views where the perspective can change instantaneously, not giving the computer any time to get textures ready.

Playing more than one game

The more content can be cached in RAM, the less disk usage there needs to be for subsequent games. Also, unused RAM just sits there, doing nothing. All it does is sit there and look nice in the task manager. In modern operating systems it is used to cache commonly used programs and files, but K2 knows better than the operating system which files will be needed the most. The difference is simply that the OS hides the fact that it is being used.

Windows Workarounds

  • Windows XP
    • Solution 1: Increase the userspace
    • Solution 2: Use OpenGL
      • Under display options change the renderer from direct3d to opengl
        • can also be done via the commandline with -vid vid_gl2


  • Windows Vista/7
    • Solution 1: Increase the userspace
      • Start->"search for programs and files"->"cmd". Right click cmd.exe and select "Run as Administrator". Then enter:
        • bcdedit /set IncreaseUserVA 2900 (The /3gb break would be 3072 but this restricts the memory pool too much)
      • Restart Windows
    • Solution 2: Use OpenGL
      • Under display options change the renderer from direct3d to opengl
        • can also be done via the commandline with -vid vid_gl2
Retrieved from "http://forums.heroesofnewerth.com/wiki/index.php/K2_Memory_Usage#Windows_Workarounds"