News - ASUS sandwiches two GeForce GTX 285 GPUs, creates a graphics monstrosity

[Biscuit]

woah madness! Power usage might be 'interesting'

[HSK]

"Limited Edition 1/1000"

So it looks like they might only be dropping a thousand of these monsters. Price will be pretty monster too.

[superscaper]

On a 32 bit OS.

What's that got to do with it?

[Barkotron]

What's that got to do with it?

32-bit OS = 4GB virtual address space, graphics cards included.

4GB virtual address space - 8GB Graphics RAM = -4GB virtual address space available for everything else to use.

Not that it would show up like that, but something's going to go badly wrong somewhere. I don't know if you'd even be able to boot into an OS tbh. I wouldn't even want to use one of these cards on a 32-bit system, although I'd be interested to see what happened.

[superscaper]

4GB virtual address space - 8GB Graphics RAM = -4GB virtual address space available for everything else to use.

It's nowhere near 1:1 though. 8 GB of Graphic RAM would not take up 8 GB of virtual address space. Yes you'd take a hit but you wouldn't necessarily lose all the available RAM or even necessarily have problems. Not saying you wouldn't have problems but there's nothing to explicitly point to having any problems on a 32 bit system.

[Barkotron]

It's nowhere near 1:1 though. 8 GB of Graphic RAM would not take up 8 GB of virtual address space. Yes you'd take a hit but you wouldn't necessarily lose all the available RAM or even necessarily have problems. Not saying you wouldn't have problems but there's nothing to explicitly point to having any problems on a 32 bit system.

Nope, that's exactly what happens.

http://www.dansdata.com/askdan00015.htm

[PeterStoba]

I have a strange feeling this won't work very well

[Nelviticus]

I'm sure this "your graphics card will eat up your address space" stuff is just hogwash but I'd love to see someone at Hexus look into it properly. When I upgraded from a 256MB card to a 512MB card - on a 32-bit system with 4GB of RAM - my available memory dropped by precisely zero bytes. It was 3.25GB with the 256MB card and it remained at 3.25GB with the 512MB card.

The way I understand it, your system doesn't address the gfx card's memory directly, it addresses the gfx card itself and the card addresses its own video memory.

To complicate matters though if you run a game which can take advantage of huge amounts of video memory it will probably need to keep a copy of video memory in main (system) memory, which I imagine can lead to problems when you have oodles of gfx memory on a 32-bit OS.

So "the way I understand it" could be summed up as 'barely', 'vaguely', 'based on hearsay and ill-informed conjecture' or quite probably 'wrongly'. But I'd love to see someone look into it properly.

[Boogle]

I suspect you'd lose 2GB virtual address space since it's SLI on a single card. If it were two physical cards, then you might lose 4GB space (although I suspect the card or chipset will have a condition in it to deactivate cards that would use up all the addressable space).

[Barkotron]

I'm sure this "your graphics card will eat up your address space" stuff is just hogwash but I'd love to see someone at Hexus look into it properly. When I upgraded from a 256MB card to a 512MB card - on a 32-bit system with 4GB of RAM - my available memory dropped by precisely zero bytes. It was 3.25GB with the 256MB card and it remained at 3.25GB with the 512MB card.

The way I understand it, your system doesn't address the gfx card's memory directly, it addresses the gfx card itself and the card addresses its own video memory.

To complicate matters though if you run a game which can take advantage of huge amounts of video memory it will probably need to keep a copy of video memory in main (system) memory, which I imagine can lead to problems when you have oodles of gfx memory on a 32-bit OS.

So "the way I understand it" could be summed up as 'barely', 'vaguely', 'based on hearsay and ill-informed conjecture' or quite probably 'wrongly'. But I'd love to see someone look into it properly.

Sounds like "something else" (physical/bios-related maybe) was preventing you seeing all your installed RAM anyway, so when the extra 256MB from the virtual address space was chomped with the new graphics card, it didn't effect the amount of physical RAM you saw.

[Boogle]

To complicate matters though if you run a game which can take advantage of huge amounts of video memory it will probably need to keep a copy of video memory in main (system) memory, which I imagine can lead to problems when you have oodles of gfx memory on a 32-bit OS.

So "the way I understand it" could be summed up as 'barely', 'vaguely', 'based on hearsay and ill-informed conjecture' or quite probably 'wrongly'. But I'd love to see someone look into it properly.

A basic optimisation of video games is to delete textures from system memory once they're sent to the GPU. The API (DX/OpenGL) and driver then handles the texture from there, either keeping it in system memory of video memory - but not both places at the same time. The same goes for vertex data, although quite often vertex data is kept in system memory by the game if it's likely to be updated/changed or needed for collision detection / other uses. The exception to all of this is DX, when the context is lost, DX dumps all the video memory so the game needs to reload it all (hence why alt+tab with DX games can take forever).

The virtual address space info is correct, to a point. As you said we don't know exactly how graphics cards work, and that's on purpose by the manufacturer. Basically a device is accessed through memory addresses, anything that isn't mapped can't be used directly. So all public registers are always mapped to virtual memory, that's so the driver and other programmers can tell the device what to do. Now, device memory is often mapped to virtual memory as well so that it can be filled up quickly 'in one big lump' (and read for that matter). I suspect in the case of devices with LOTS of memory (like GPUs with large framebuffers) not all the memory is addressed. The disadvantage is you have an extra level of indirection, and you can't just send a load of data in one go, it has to be sent in waves and the GPU then moves it around or just changes the memory mappings. To the programmer this is invisible, the driver / API handles this, so to the programmer, they can address all the memory as if it were continuous. I suspect this may be another reason why sending new data to the GPU can result in heavy performance penalties - outside of just basic bandwidth constraints, and other optimisations from static rather than dynamic data. Edit: Would just like to point out, that under no circumstances would the driver access the 'GPU itself', that would mean sending data to registers and then the GPU moving that to memory. It would be ludicrously slow to do this, since you would be working on very small pieces of data at a time (128bit GPU, say 10 registers, that's barely over 1MB total), and requiring GPU cycles purely for moving data. The graphics card will present video memory directly for filling in large chunks, how big these chunks are... well, who knows. It could even be arch-specific (guessing here), so a 64bit arch exposes all the memory, while 32bit exposes, say 256MB.

Back in ye olde DOS days, the 1:1 mapping of virtual memory was a pretty accurate assessment, a lot of apps accessed devices directly without using drivers. But in Windows and other OS, we now have drivers which abstract the device. This means it's up to the manufacturer as to how they expose and map everything.

[kalniel]

With XP it's as some people are describing.

But in the Vista WDDM and the direct10 model the video ram is addressed as part of the system virtual memory address space. The problem comes if you're playing a directX9 game which is therefore written to address the virtual address space on the card rather than the system. Prior to SP1 vista duplicated the cards virtual address space in this situation causing a huge amount of the virtual address space to be taken up, and the larger the vid card ram the worse the problem. Read MS KB940105 for more details.

Post SP1/kb940105 it's less of a problem, but the vram is mapped to the system virtual address space, leaving fewer addresses available for everything else, drastically so in 32bit systems when the card has a large amount of memory.

[Barkotron]

With XP it's as some people are describing.

But in the Vista WDDM and the direct10 model the video ram is addressed as part of the system virtual memory address space. The problem comes if you're playing a directX9 game which is therefore written to address the virtual address space on the card rather than the system. Prior to SP1 vista duplicated the cards virtual address space in this situation causing a huge amount of the virtual address space to be taken up, and the larger the vid card ram the worse the problem. Read MS KB940105 for more details.

Post SP1/kb940105 it's less of a problem, but the vram is mapped to the system virtual address space, leaving fewer addresses available for everything else, drastically so in 32bit systems when the card has a large amount of memory.

That's not quite the same thing, although it does show why this area gets so confused. Each application on a 32-bit Windows system (by default, ignoring e.g. the /3GB boot.ini switch) gets 2GB of virtual address space "of its own" for it to manage the way it sees fit. This is not the same virtual address space as the 4GB system virtual address space. That KB article discusses applications running out of their virtual address space because the application itself has been written to use that address space to keep a copy of the video RAM.

The issue with MMIO on 32-bit systems is that eating into system virtual address space can cause actual Physical RAM to be masked out of the system, which means that those physical RAM chips can't be used, which means you start paging sooner and don't get the benefit of all the RAM you've installed.

Scenario:

Windows Whatever 32-bit
4GB physical RAM
1GB Video Card Of Whatever Flavour You Prefer

Assuming nothing else is clouding the issue (as seen in Nelviticus' post), this system would show up, under System Properties, as having slightly under 3GB of physical RAM installed. 4GB, minus the various MMIO slots of the different devices making up a reasonably small chunk, minus the 1GB chunk used for MMIO to the video card RAM.

This shouldn't be all that much of a problem unless you actually start using more than 3GB-minus-a-bit of that physical RAM, at which point you're going to start swapping out, which is a massive performance hit. That last 1GB won't get used at all, so you've wasted however much money it was you spent on it.

I have absolutely no idea what would happen if you tried to put one of these cards in 32-bit system, let alone 2. There's no way to map that 4GB as well as the rest of the MMIO stuff without it overflowing the available 32-bit memory address space. I'd guess Windows would just refuse to boot, but to be honest I have no idea.

Best bet - go to a 64-bit OS and install as much RAM as you can afford . There's not much reason not to these days.

[shaithis]

A couple of caveats...just to muddy the waters a little more

There are ways around it, although for home use the price is rather excessive compared to installing a 64 bit OS......

Windows Server Enterprise Editions will allow many Gigabytes of RAM in 32bit.

And 32bit apps can address 4GB of RAM if compiled to be LMA aware.

[Main]

That thing is going to sound like a jet engine just to get enough air through it...

[kalniel]

That thing is going to sound like a jet engine just to get enough air through it...

Does the 285 require more cooling than the 275 then?