Crawl
In the near term, vendors and software developers must support both x86 and x64 versions of Windows. For application developers, this means making sure that their 32-bit applications work correctly on Windows x64 under WOW64. Game developers can take advantage of huge increase in memory support for content creation, servers, and development stations.
As with all technology transitions, customer demand tends to drive many companies to support Windows x64. Having said that, it is no longer “early adopter hell.” I personally run Windows XP Pro X64 and Windows Vista x64 on my development systems, Windows Vista x64 on my laptop, and Windows Vista x64 at home for my gaming machines.
Based on the download statistics for KB940105, and driver packages from major video hardware vendors, we estimate that a quarter of the hardcore gamer market that adopted Windows Vista is running 64-bit versions.
Market realities, however, dictate that most games need to be playable on 32-bit systems for the coming years. Therefore, making sure your 32-bit game runs well on both x86 and x64 versions of Windows is a basic shipping criterion. Just as with previous OS transitions, Windows x64 is a better development environment. It is a safer bet that a 32-bit program that runs well on Windows x64 will run perfectly fine on x86 versions than vice versa.
Transitioning to Windows x64 also greatly expands your options. You can introduce 64-bit native versions of tools into your pipeline. Also, LAA 32-bit tools get maximum memory benefits. The Visual Studio linker, for example, is an LAA application. For large monolithic executables, this can mean the difference between being able to enable Whole Program Optimization and failing to link.
A 64-bit version of a level editor or 3D modeler can enable you to work on whole levels without having to deal with time-consuming “chunking” workarounds. Running a 64-bit operating system means that you can install 8 GB or 16 GB of physical memory, instead of being limited to less than 4 GB. This means you can load huge data sets without paging. Often, the disk cache will keep all of the files you are working on in RAM.
Walk
Basic compatibility with Windows x64 for your 32-bit applications and moving your internal systems over is a good first step. The real value for customers will come from taking advantage of Windows x64. Some showcase games have already provided 64-bit native versions of their game. However, not every studio has the option of creating, testing, and optimizing two distinct versions of their title.
One solution is to take advantage of Large Address Aware (LAA) in your game to allow scaling content beyond the 2 GB Limit, while keeping to a single 32-bit executable. The highest-detail settings would be available only when you run the game on Windows x64, or when you use additional memory for larger resource caches to improve the overall player experience, based on a call to GlobalMemoryStatusEx.10
For networked games with a server infrastructure, Windows x64 64-bit native server programs can take advantage of both the extra physical RAM support and the greatly expanded virtual memory space for more aggressive memory-mapped I/O usage. Making your server 64-bit native enhances the development team’s expertise in 64-bit programming. At the same time, it reduces the impact on the content team, and running 64-bit native executables can greatly improve the performance and stability of your servers running in the datacenter.
Run
Once games demonstrate better content running on 64-bit versions of Windows, the business case for making a 64-bit native version of the game becomes more realistic. Smaller games that fit comfortably into the 2 GB limits of 32-bit processes have no particular need for 64-bit native versions in the short term. On the other hand, AAA titles are already transitioning to 64-bit native executables. In some cases, these are purely internal builds to better handle debugging, unoptimized content, and rapid iteration. In the long run, it will make sense to ship these to customers.
Shipping 64-bit native applications will become the norm as 32-bit systems are retired or upgraded. Even many laptops are x64 capable. In fact, today’s gaming laptops often come with 4 GB or more RAM. While the use of 64-bit pointers can increase an application’s memory footprint somewhat, structure packing and optimization can bring a 64-bit application in line with an equivalent 32-bit application.
Such x64 native applications gain the performance benefits of extra registers. They can assume SSE2 to transition away from the less efficient x87 FP stack model. They also eliminate the fairly small marshaling costs of Win32 system calls on Windows x64 bypassing WOW64. Future development efforts of processors, compilers, and other tools will shift from being 32-bit focused to 64-bit. At that point, memory addressability is no longer the primary driving reason to move to x64 native applications.
There are two main challenges to the future of x64 native games beyond the traditional issue of market penetration and adoption: third-party “middleware” solutions and tools and the use of deprecated technologies.
10 “64-bit programming for Game Developers,” Specifying Large-Address-Aware When Building, DirectX SDK Documentation.
|
Part 1 - Practical Problems With 32bit Addressing In Windows (description and test of current games without LAA boot)
http://www.anandtech.com/gadgets/showdoc.aspx?i=3034
Part 2 - Windows XP, Vista, and the 2GB Barrier: (Comparison of Vista/XP virtual memory usage of games)
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3044
Part 3 - Vista Buys Some Time: (Testing the KB940105 Hotfix)
http://www.anandtech.com/systems/showdoc.aspx?i=3060
This is not entirely true, depending on what metrics you use for the "distance from the barrier". Part of the problem is memory fragmentation, and the position of the "hole" created by the allocation differs depending on its size.
The game will usually "hit the 2GB barrier" way before it uses 2 GB of virtual space.
The first mitigation effort for all the titles hitting this problem was to reduce vm fragmentation. Glaring problems are easy to fix, but games have been dealing with this concern for a while. Many AAA titles with full content are very close to filling up the 2 GB of VAS available to standard 32-bit apps. While KB9410105 brings the memory usage inline with XPDM to eliminate the Windows XP vs. Windows Vista differences, it doesn't change the fact that games are wanting to include more and more content.