Tom's Hardware Sits Down With Chuck Walbourn

To get a better sense for where we are now versus when Microsoft’s Chuck Walbourn made his two Gamefest presentations, we recently caught up with him and asked a handful of questions related to 64-bit gaming. Before you dig in, check out the story he wrote for Gamasutra on gaming, memory, and 64-bit computing, which serves as a great primer for our discussion.

Chris Angelini: In testing for this piece, I observed very little in the way of performance improvement, given a shift from 32-bit to 64-bit operating environments. What gives?

Chuck Walbourn: This goes to the fundamental issue with x64 64-bit technology: it doesn't so much "go faster" as it enables new scenarios without giving up performance running 32-bit applications. This is a pretty key issue for adoption. x64 technology "just works" and means you are not giving up anything to get 64-bit capabilities. Technically you are giving up the ability to natively execute 16-bit code when running your processor in 64-bit mode (which is the case when running Windows x64), but that's just a hardware manufacture’s tradeoff to limit compatibility with ancient code that dates back to the Windows 3.1 days.

Chris Angelini: What’s the justification for adding memory to my system, then, if I am a game developer?

Chuck Walbourn: The most obvious reason to move to a x64 OS is larger memory support. As my Gamasutra article discusses, if you have 4 GB or more of RAM installed in your system, you are wasting hardware to run anything but a x64 OS. This manifests itself in some ways just doing daily work: larger file cache and can have more processes running at once (particularly important if you have a beefy four- or eight-core machine). We've seen a number of game developers adopt x64 pretty strongly just for this reason even when they are not using any 64-bit native applications at all. An eight-core machine with 16 or 32 GB of RAM running Windows Vista x64 can crank through code builds like nobody's business when using a multi-threaded build environment. DICE, Epic, Valve, Crytek, Starbreeze, and others game developers all are standardizing on x64 machines for development to be able to use large amounts of RAM, especially given how quickly memory prices are falling for these configurations.

Once the 64-bit capability is there, that's when things get interesting.

Chris Angelini: One of your calls to action was for developers to enable /LAA, at least. Is there an easy way to tell who has heeded your device and actually done that?

Chuck Walbourn: We've had "Large Address Aware" for years, but its use has always been limited to some hardcore technical scenarios because actually booting the 32-bit OS so that you can take advantage of it is tricky. The point of my Gamefest 2007 talk was that Windows x64 makes "Large Address Aware" potentially a painless consumer scenario if they are running a Windows x64 machine. Now, there are plenty of caveats to using LAA for the developer, especially with respect to 3rd party libraries and legacy code, and it only gets your application to 4 GB of address space rather than the full 8 TB. Still, it is a useful bridge technology for letting your existing 32-bit application scale beyond 2 GB and giving users of Windows x64 systems some better detail textures, larger streamed data caches, or whatever else would never have fit into the limits of a standard 32-bit application.

For game developers, they are already hitting the wall with the 2 GB limit for their content. For Crysis, Crytek had to make a x64 native editor in order to be able to create levels that completely filled the 2 GB space available for standard applications when fully optimized, but would not be able to run the editable version at all as a standard 32-bit application. Flagship Studios made extensive use of x64 native server programs, making those processes more resilient to memory space fragmentation. The Visual Studio linker has been an LAA application for years, and by using it on a Windows x64 system, developers have been able to link huge monolithic game .exes with more optimizations enabled than would work otherwise. We've seen LAA used in combination with Windows x64 for other tool sets as well, and a number of those teams are now moving to x64 native versions. There's plenty of value already there to move studios over to x64. LAA-enabled tools and content pipelines, plus the strong push from the Digital Content Creation applications like 3ds Max, Maya, SoftImage for x64 native tools, are making it a critical enabling technology, even when shipping games on existing platforms like 32-bit PC, Xbox 360, etc.

As for which games are LAA: there are many that enable it. If you search the Web, you'll see a lot of enthusiasts are hacking existing games to enable LAA to try to make them more stable when running big mods. Some games also quietly suggest in support forums to run on Windows x64 to resolve stability issues for long play sessions, complicated levels, etc. The 2 GB 32-bit limit of applications has been a huge point of pain in the game industry for many years now, so there's plenty of pent-up demand for moving beyond it. LAA on Windows x64 gives some breathing room, and more important, it gives gamers a solid reason for adopting the technology before x64-native games becomes common-place.

Chris Angelini: How about the benefit to gamers?

Chuck Walbourn: For consumers, 4, 6, or 8 GB of RAM is pretty cheap these days. And without Windows x64 you really have to stick to about 3 GB of RAM total. While the number of x64 native games is still small, the acceleration in the market of Windows x64 driven by memory sizes makes it more interesting over time. LAA-enabled titles right now typically give a more stable experience when running on Windows x64 because they have much more headroom in the very tight 2 GB address space environment for modern AAA titles. But developers can also deliberately throw in more content in this situation when enough users have the systems to support it.

Recent data is showing a strong uptick in the numbers of Windows x64 systems out there, and game developers have wanted to get past the pains of the 2 GB limit for some time now. In today's market, it is a difficult pitch to make a x64 native-only game, and making both a 32-bit and a x64 native version of the game is more work and risk than many teams are wanting to take on right now. Game content is getting more detailed every year, and if your game is going to stand out, you'll want to be on the high end of that curve. The game industry has also been making more and more use of third party middleware solutions for their titles, and it's been a difficult process to get all the various companies providing these solutions to really engage on providing x64 native support. This is starting to accelerate as well, which should enable more developers that are otherwise stuck deciding between writing their own technology solutions that support x64 native or shipping on time.

Chris Angelini: How far off are we from seeing a more wholesale shift to native 64-bit game titles? What will they offer above and beyond the 32-bit versions seen today?

Chuck Walbourn: x64-native games are pretty limited today, and most of them are "early-adopter" titles. We hear that there are a number of studios who use x64 native builds of the game internally for development, but the publishers don't want to pay for the costs of testing and supporting them right now. Once we get a point where developers and publishers do focus on making x64-native versions of games, there are some performance improvements that can be had with more registers, better SSE2 SIMD utilization, aggressive use of memory mapped I/O, and significantly larger assets. Right now the real point is to be able to get past the 2 GB squeeze before we see major performance wins from software optimization reappear.

Chris Angelini: A big thanks to Chuck for weighing in on an issue that promises to shape the way games are developed in the years to come.