<?xml version="1.0" encoding="UTF-8" standalone="yes"?><oembed><version><![CDATA[1.0]]></version><provider_name><![CDATA[Krzysztof Narkowicz]]></provider_name><provider_url><![CDATA[https://knarkowicz.wordpress.com]]></provider_url><author_name><![CDATA[Krzysztof Narkowicz]]></author_name><author_url><![CDATA[https://knarkowicz.wordpress.com/author/knarkowicz/]]></author_url><title><![CDATA[Virtual memory on&nbsp;PC]]></title><type><![CDATA[link]]></type><html><![CDATA[<div>
<p>There is an <a href="http://solid-angle.blogspot.com/2011/02/virtual-addressing-101.html">excelent post</a> about virtual memory. It&#8217;s written mainly from a perspective of console developer. On consoles most of memory issues are TLB misses and physical memory limit. I&#8217;ll try to write more about how (bad) it looks on PC (windows) with 32 bits programs. Especially nowadays when games require more and more data.</p>
</div>
<p>Firstly half of program&#8217;s virtual address space is taken by kernel. This means that first pointer&#8217;s bit is unused and it can be used for some evil trickery :). Moreover first and last 64kb are reserved by kernel.</p>
<p>Program&#8217;s source and heap has to be loaded somewhere. When compiling using VC++ default place is 0x0040000. Then a bunch of DLLs are loaded into strange virtual memory addresses. You can check what DLLs are loaded, into what address and see their size using <a href="http://www.dependencywalker.com/">Dependacy Walker</a>. Use start profiling feature to see real virtual memory address of given DLL. DLLs and program usually aren&#8217;t loaded into one contiguous address range. At this point we didn&#8217;t call new/malloc even once and virtual memory is already fragmented.</p>
<p>Now there comes video driver. It will use precious virtual memory for managed resources, command buffer and temporary for locking non managed resources. Especially creating/locking non managed resources is quite misinforming as DirectX returns &#8220;out of video memory&#8221; instead of &#8220;out of virtual memory&#8221;. It&#8217;s very tempting to put all static level geometry into one 100mb non-managed vertex buffer. When creating/filling this VB video driver will try to allocate contiguous 100mb chunk of virtual memory. This will likely result in program crash after some time.</p>
<p>Windows uses 4kb pages, so doing smaller allocations will lead to internal fragmentation. I guess already everyone is using some kind of custom memory allocator, so it isn&#8217;t a problem.</p>
<p>There is /LARGEADDRESSAWARE linker flag, which allows to use additional 1gb of virtual memory. It requires user to change boot params and usually doesn&#8217;t work well in practice (system stability issues etc.). It&#8217;s also possible to compile as 64 bit program, but according to <a href="http://store.steampowered.com/hwsurvey?platform=pc">Steam HW survey</a> half of gamers use a 32 bit OS. This is really annoying that MS is still making 32 bit systems because currently min PC game spec CPUs are core2 or similar with 64 bit support.</p>
<div>
<p>Summarizing in theory memory shouldn&#8217;t be a problem on PC, but in practice it&#8217;s a precious and fragile resource.</p>
</div>
]]></html></oembed>