32bit XP/Vista limits video memory usage?

tEd

Casual Member
Veteran
From a Tim Sweeny interview:

Q. Does Unreal Tournament 3 take advantage of over 512MB of video memory?

A. We’re going to significant lengths to take advantage of 512MB video cards and PCs with lots of memory. On PC, we’re shipping lots of 2048x2048 textures, a higher resolution than we can support pervasively on console platforms. However, PCs running 32-bit Windows XP or Vista run up against a glass ceiling pretty quickly above 512MB of video memory. Because of the way the OS maps video memory into the 32- bit address space, going beyond 512MB doesn’t really increase the overall usable memory. Thus, we’re not focusing on exploiting more than 512MB video cards.


Thoughts? Explanations?
 
Whatever textures or resources you load into VRAM you usually also need to store a copy in system RAM, to support alt-tab and stuff like that. 32-bit programs only have 2gb of memory they can use before the address space barrier is hit, so perhaps he's saying that using over 1/4 of system RAM just for graphics is a little excessive.
 
Especially when you consider there's a growing number of games that are already exceeding the 2 gig virtual addressing limit in 32 bit versions of Windows.

Both Supreme Commander and Vanguard come to mind. At least Supreme Commander you can do something about with a 64 bit OS and Editbin.exe. Vanguard however, you can't do anything about as the exe must be validated at the server. So at 1920x1200 res, a crash to desktop is only a few chunks away in VG.

I suspect that until the industry moves fully to Vista 64 that it will be extremely unlikely to find many (if any) games exploiting more than 512 megs of video memory.

So lets all cross our fingers and hope the move to a 64 bit OS occurs sooner rather than later.

The sooner the 32 bit OSes die, the better off gamers will be.

Regards,
SB
 
Ujm, it seems strange that noone mentions that while system may allocate videoram, some for textures, some for blah, blah, blah, the gpu itself will use additional ram as well. Just becasue cpu cannot adress it does not mean gpu cannot use it!

:rolleyes:
 
Both Supreme Commander and Vanguard come to mind. At least Supreme Commander you can do something about with a 64 bit OS and Editbin.exe. Vanguard however, you can't do anything about as the exe must be validated at the server. So at 1920x1200 res, a crash to desktop is only a few chunks away in VG.

That was fixed last patch with textures no longer being stored in ram. The only crashes from chunking now are from 8800 owners and nvidia driver bugs with Vanguard causing memory leaks.
 
That was fixed last patch with textures no longer being stored in ram. The only crashes from chunking now are from 8800 owners and nvidia driver bugs with Vanguard causing memory leaks.

Is it really driver bugs? The VG crashes on 8800 cards have been around since beta and it's the only game that displays that kind of behaviour (heavy hitching and then crashing, often with the compiled shader cache files getting corrupted).
 
Is it really driver bugs? The VG crashes on 8800 cards have been around since beta and it's the only game that displays that kind of behaviour (heavy hitching and then crashing, often with the compiled shader cache files getting corrupted).

Well I guess I'm far from an expert so I couldn't really say for sure whether it's solely Vanguard, a combination of the 2 ( more likely) or just Nv's drivers. I know it only happens on 8800 series cards though, and isn't limited by specific boards or GTS/GTX.

I'm hoping it is something to do with the texture memory issue on 8800's causing slow down until it's reset (which is why flushing works in Vanguard for this problem). Considering it's the only card in Vanguard that gets memory allocation errors, it's kinda likely. So when nvidia fixes that problem, possibly this will be fixed in Vanguard as well.
 
Well I guess I'm far from an expert so I couldn't really say for sure whether it's solely Vanguard, a combination of the 2 ( more likely) or just Nv's drivers. I know it only happens on 8800 series cards though, and isn't limited by specific boards or GTS/GTX.
I know several people who ran VG on 320mb GTS cards with no problems at all, most people I talked to who suffered from the crashes had 640 or 768 mb cards.
 
That was fixed last patch with textures no longer being stored in ram. The only crashes from chunking now are from 8800 owners and nvidia driver bugs with Vanguard causing memory leaks.

I wish it was fixed. Unfortunately running a HD 2900 XT or a X1800 XT will result in a crash to desktop after chunking 1 time (to NT or Khal) or chunking rom 1-6 times in less populated areas of the game.

Using Process Explorer (I think that's the program I'm not at the gaming computer at the moment) from Sysinternals you can monitor Virtual Addressing. Soon after it reaches 2 gigabytes VG will immediately crash to the desktop.

You an alleviate this problem somewhat by doing any of the following...

1. Run WinXP, the new Video Memory manager in Vista appears to use an large bit of virtual addressing when running games. The more memory on the video card, the more virtual addressing used.
2. Run a video card with less than 512 megs of memory, if running Vista.
3. Run with reduced graphics settings or reduced resolution.

Of course, all of that just prolongs the inevitable. The more you chunk, the more Virtual address appear to be retained (I'm guessing to reduce the time it takes to rechunk to a chunk you've recently left?). A friend on WinXP with a 7950 GXP (that's the dual slotter correct?) experiences the same crash to desktop playing on WinXP at 1600x1200 (I play at 1920x1200), however it takes her significanly longer playtime/chunking before she'll crash to destop from hitting the 2 gig virtual addressing wall.

Now if only VG was large address aware, at least I wouldn't have as much of an issue in Vista 64, but unfortunately they haven't flagged it with that flag.

Each patch I keep hoping it's fixed (was pretty much rock stable on my X1800 XT prior to the 5/11 patch), and each patch I zone to Khal or NT, run to broker and promptly CTD as Virtual Addressing hits 2 gig.

Most of my guild has since quit playing the game directly due to continuous CTDs on a variety of graphics hardware. Although players with 512 meg graphics cards playing at high res were hardest hit.

Regards,
SB
 
I am curious how these memory limitations in 32 bit OS affect things like framebuffer storage. In accounting to textures. Lets say said title uses 512 megs of memory. And you are running 8xAA @ 2560x1600. Would framebuffer be impacted by this because at this point your significantly above 512 megs of storage space.

Chris
 
Framebuffers aren't stored in system RAM (usually, at least). So in all likelihood, you'd just get some of that 512mb of textures paged out to system RAM to make more space in VRAM.
 
I wish it was fixed. Unfortunately running a HD 2900 XT or a X1800 XT will result in a crash to desktop after chunking 1 time (to NT or Khal) or chunking rom 1-6 times in less populated areas of the game.

Most of my guild has since quit playing the game directly due to continuous CTDs on a variety of graphics hardware. Although players with 512 meg graphics cards playing at high res were hardest hit.

Do you actually have the option turned on? In your vgclient.ini look for bUseEfficientTextures which you want set to True. My whole guild no longer gets crashes apart from some people with 8800s. The patch worked wonders for 90% of the playerbase.
 
Do you actually have the option turned on? In your vgclient.ini look for bUseEfficientTextures which you want set to True. My whole guild no longer gets crashes apart from some people with 8800s. The patch worked wonders for 90% of the playerbase.

I'll have to check when I get back to Japan. I'm currently on "vacation" (if you call sweating your arse off while doing nothing a vacation :rolleyes: ) in Taiwan right now, so all I have access to is my laptop.

Regards,
SB
 
I suspect that until the industry moves fully to Vista 64 that it will be extremely unlikely to find many (if any) games exploiting more than 512 megs of video memory.

So lets all cross our fingers and hope the move to a 64 bit OS occurs sooner rather than later.

The sooner the 32 bit OSes die, the better off gamers will be.

Regards,
SB

Seeing as how MS has only just released to market their first "mainstream" 64-bit O.S., and still plans to ship 32-bit versions of the next O.S. due out in '09 or '10 (Vienna), I don't think we'll be seeing 64-bit Windows installed-base overtaking that of 32-bit Windows anytime soon.

Don't take this to mean that I think this is a good thing, 64-bit is definitely better than 32-bit and we need the larger addressing capability like yesterday, I'm just stating the reality of the situation.
 
Nope, that isn't exactly what I'd call a fix for Vanguard. bUseefficientTextures=True just makes the textures in game lower resolution. It also appears to turn off some of the shaders used on textures. Many textures become "plasticy" when lighted. And most ground and wall textures become "one-dimensional".

It also doesn't prevent the CTD's in Vanguard. It just prolongs it by lowering the starting Virtual Addresses. Rather than starting at around 1.5-1.6 gigs in Khal it starts at around 1.1-1.2 gigs in Khal when first logging in. I imagine 8800 GTX/Ultra users have it worse off as they have another 256 megs onboard eating up Virtual Addressing.

So rather than just porting from Khal to New Targonar and then running to the crafting area for a guaranteed CTD (reaches 2 gigs virtual addressing usually around the first or second "tunnel" in the city proper), I can now port from my House to Khal then port to New Targonar and run to the crafting area and it'll be a 100% CTD somewhere around the crafting area.

So a slight improvement but nothing that's going to prevent CTD's and it comes at a VERY large graphics quality hit.

Here's to hoping the next patch reverses whatever the hell they did to break things in the 5/11 patch.

Regards,
SB
 
Back
Top