A Messy Transition (Part 3): Vista Buys Some Time
by Ryan Smith on August 13, 2007 3:00 PM EST- Posted in
- Systems
As we saw in part 1 of this series, large applications and games under Windows are getting incredibly close to hitting the 2GB barrier, the amount of virtual address space a traditional Win32 (32-bit) application can access. Once applications begin to hit these barriers, many of them will start acting up and/or crashing in unpredictable ways which makes resolving the problem even harder. Developers can work around these issues, but none of these except for building less resource intensive games or switching to 64-bit will properly solve the problem without creating other serious issues.
Furthermore, as we saw in part 2, games are consuming greater amounts of address space under Windows Vista than Windows XP. This makes Vista less suitable for use with games when at the same time it will be the version of Windows that will see the computing industry through the transition to 64-bit operating systems becoming the new standard. Microsoft knew about the problem, but up until now we were unable to get further details on what was going on and why. As of today that has changed.
Microsoft has published knowledge base article 940105 on the matter, and with it has finalized a patch to reduce the high virtual address space usage of games under Vista. From this and our own developer sources, we can piece together the problem that was causing the high virtual address space issues under Vista.
As it turns out, our initial guess about the issue being related to memory allocations being limited to the 2GB of user space for security reasons was wrong, the issue is simpler than that. One of the features of the Windows Vista Display Driver Model (WDDM) is that video memory is no longer a limited-sharing resource that applications will often take complete sovereign control of; instead the WDDM offers virtualization of video memory so that all applications can use what they think is video memory without needing to actually care about what else is using it - in effect removing much of the work of video memory management from the application. From both a developer's and user's perspective this is great as it makes game/application development easier and multiple 3D accelerated applications get along better, but it came with a cost.
All of that virtualization requires address space to work with; Vista uses an application's 2GB user allocation of virtual address space for this purpose, scaling the amount of address space consumed by the WDDM with the amount of video memory actually used. This feature is ahead of its time however as games and applications written to the DirectX 9 and earlier standards didn't have the WDDM to take care of their memory management, so applications did it themselves. This required the application to also allocate some virtual address space to its management tasks, which is fine under XP.
However under Vista this results in the application and the WDDM effectively playing a game of chicken: both are consuming virtual address space out of the same 2GB pool and neither is aware of the other doing the exact same thing. Amusingly, given a big enough card (such as a 1GB Radeon X2900XT), it's theoretically possible to consume all 2GB of virtual address space under Vista with just the WDDM and the application each trying to manage the video memory, which would leave no further virtual address space for anything else the application needs to do. In practice, both the virtual address space allocations for the WDDM and the application video memory manager attempt to grow as needed, and ultimately crash the application as each starts passing 500MB+ of allocated virtual address space.
This obviously needed to be fixed, and for a multitude of reasons (such as Vista & XP application compatibility) such a fix needed to be handled by the operating system. That fix is KB940105, which is a change to how the WDDM handles its video memory management. Now the WDDM will not default to using its full memory management capabilities, and more importantly it will not be consuming virtual address space unless specifically told to by the application. This will significantly reduce the virtual address space usage of an application when video memory is the culprit, but at best it will only bring Vista down to the kind of virtual address space usage of XP.
Facebook
Twitter
RSS
37 Comments
View All Comments
Ryan Smith - Tuesday, August 14, 2007 - link
You're right in that the 2GB barrier seems academic when we have the 4GB limit right above that, but in practice it's not. All 3 of the major games we listed run just fine with 2GB of RAM, yet all of them were prone to crashing due to running out of virtual address space(especially under Vista) which means that the real problem is the 2GB barrier and not the 4GB limit. In other words developers don't have another 2 years to put off worrying about some "way off in the future" problem, they must start doing so today.You're probably right in that we're going to see some developers tighten up their code in the face of the 2GB barrier. I fear we may also see them simply stop raising the bar altogether, and turn the PC in to some twisted static console.
leexgx - Tuesday, August 14, 2007 - link
i beleve windows only alowes 2gb (+2gb virtual) in 32bit mode (even if the OS is 64 bit if the program is 32bit windows 64 uses the same rules as 32bit os for compatiblity so its stuck with 2gb realy untill programs become native 64bit but thats an long time before that ever happens 5-8 years maybe)bsteff - Monday, August 13, 2007 - link
I will NEVER use any form of Vista because I am unalterably opposed to the DRM and the insulting philosophy behind it. As a Physician who uses a Windows XP machine to view critical patient images, I cannot tolerate the "tilt bits" and degradation that Vista will cause. Maybe one day Microsoft will get this DRM right but it usually takes them at least 3 tries and neither I nor my patients can take that chance! (automatic image degradation, processing slowdown, etc.if DRM violation is suspected by Vista) The memory problem is the last straw as it is obvious that MS wants to use the flaws in XP 64 bit to drive users into Vista (and give MS control of their own machines) For me the only way to go is Linux/Unix. What MS does is irrelevant. I am pressing our imaging software suppliers to develop for Linux and get rid of the entire MS problem in one fell swoop.yyrkoon - Tuesday, August 14, 2007 - link
Uh . . . O-K . . . What does that have to do with the article at hand ? No one is forcing you to use any form of Windows, and I wish you *NIX Zealots would resist 'sharing' your oposition to anything MS related, or at least stay where people may listen or believe you (slash dot ring a bell ?).Anyone who uses Windows has most likely already passed by the hurdles those of you who are opposed to using Windows have not. We really, REALLY, do not wish to 'share' in your misery . . . Next thing you know, you'll be telling us that MS is forcing you to use Windows, because application developers do not write their code for anything else . . .
You named only one reason why you would switch from Windows to Linux. I can name you 10's if not 100's of reasons why I would never switch over to Linux 100%. Driver suppport, Intuitive user interface, the OSS development model just to name three.
Now, ask me what I have just posted has to do with this article . . .
smegz68 - Monday, August 13, 2007 - link
Not only are games hamstringed by Vista. I have issues when working with large meshes and complex characters in apps like Carrara, Poser 7 and Bryce 6. Poser won't even let me load new models without locking up. When I look at the task manager, physical memory is usually maxed out at 2G or very close. The pagefile size is also right there at the 2G mark. Even running them in compatibility mode doesn't help. Thank god I still have a fast XP system I can do that work on.Ryan Smith - Monday, August 13, 2007 - link
I don't know those applications inside & outside, but I believe the answer is no. This is a fix relating to address space consumption due to video RAM usage, those applications aren't GPU accelerated in any way as far as I know.CZroe - Monday, August 13, 2007 - link
I'd still would like to see address space assignments in a system running SLi vs. one without. If address space usage can be effectively doubled in this configuration, it could make it significantly easier to hit this limit even with the patch.leexgx - Tuesday, August 14, 2007 - link
SLI systems have the same work space as one card an 7900 GTX 512 in SLI does not turn it into an 1GB video SLI system the frame buffer is still 512mb (last time i checked as Both cards Need the same Textures as both cards render half of the video thats why its was Daft calling an 7950 GX2 with 1gb of video ram when it can only Use 512MB of it)BikeDude - Thursday, August 16, 2007 - link
I think you are slightly wrong.I suspect the cards won't automatically be addressed as one (and have identical memory contents). The driver will be responsible to transfer textures to both of them, thus they will both need to be mapped into the system memory space. I.e. if you have a 4GB system memory, 32-bit Windows will forget about 2x512MB memory (given two 512MB cards) instead of just 512MB. I read one magazine that claimed they lost more system memory in a SLI system than just a regular one card system (with two 768MB cards, they were left with 2.2GB system memory).
The processes themselves will likely be unaffected, and as you say the video memory mapped into them will remain 512MB in size. (given a single card or two SLI cards w/512MB memory)
I hope more people will move to 64-bit Windows and return any hardware that doesn't offer full 64-bit support. Anything else is ridiculous at this point.
leexgx - Thursday, August 16, 2007 - link
ok the part about adress space on windows 32 with an 8800 768mb SLI, only seeing 2.2gb system ram is the driver with kernel spacewhat your saying is lost to kernel not used system ram just in this case the other half of the ram is not been used for any thing but kernel drivers (this does not happen in 64bit mode)
SLI cards max frame buffer is the size of one card Both cards need the texture data on both cards as both of them do half load rendering
if the cards are Not in SLI mode then yes both cards have inderpendent frame buffers
if any one has any hard info on this it be nice to know but i am quite sure i am right (i am not braging just from when i got my 7950GX2 as alot of reviews Pointed that out that its not 1gb card its 2x512mb in SLI so max textures before ram use is 512mb)