• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.
  • The forums have been upgraded with support for dark mode. By default it will follow the setting on your system/browser. You may override it by scrolling to the end of the page and clicking the gears icon.

NVIDIA GeForce RTX 2060 to Ship in Six Variants Based on Memory Size and Type

I talked to someone in the know about the theoretical of a 32-bit D3D10 game and how that relates to VRAM. Textures practically have to pass through the RAM to reach the VRAM. The only way to not do that is via DMA which is very fringe stuff.

My understanding is that there's a variety of ways to make it crash because that RAM limitation is absolute.
1) If you try to load too many resources, GART will overflow crashing the executable.
2) If you try to load a huge asset (depending on conditions but could be smaller than 3 GiB in size) , it will crash because the RAM can't hold the asset before handing it to the VRAM.
3) If you try to hold too many assets in RAM in transit to VRAM and you fail to release them the RAM fast enough and it goes over the virtual memory limit, it will crash.

In other words, even under 32-bit D3D10, you're dancing on a razer's edge when dealing with VRAM. VRAM (unless DMA is used which good luck with that) is practically limited by addressable RAM space.

Coming full circle, this is fundamentally why Fury X 4 GiB and GTX 970 3.5 GiB were okay a few years ago but not so much now. Any game that might need 64-bit address space is usually 64-bit. The days of claustrophobic memory usage are gone.
 
I talked to someone in the know about the theoretical of a 32-bit D3D10 game and how that relates to VRAM. Textures practically have to pass through the RAM to reach the VRAM. The only way to not do that is via DMA which is very fringe stuff.

My understanding is that there's a variety of ways to make it crash because that RAM limitation is absolute.
1) If you try to load too many resources, GART will overflow crashing the executable.
2) If you try to load a huge asset (depending on conditions but could be smaller than 3 GiB in size) , it will crash because the RAM can't hold the asset before handing it to the VRAM.
3) If you try to hold too many assets in RAM in transit to VRAM and you fail to release them the RAM fast enough and it goes over the virtual memory limit, it will crash.

In other words, even under 32-bit D3D10, you're dancing on a razer's edge when dealing with VRAM. VRAM (unless DMA is used which good luck with that) is practically limited by addressable RAM space.

Coming full circle, this is fundamentally why Fury X 4 GiB and GTX 970 3.5 GiB were okay a few years ago but not so much now. Any game that might need 64-bit address space is usually 64-bit. The days of claustrophobic memory usage are gone.
DMA access used to be everywhere a while back, not sure whether Win10 restricts is somehow (and I wouldn't be surprised if it does).
As for loading huge textures, two things. First, there's this thing called streaming - you don't have to keep the entire thing into RAM at the same time to load it. Second, I'm pretty sure no game uses a 3GB piece of texture.
 
Developers use the methods provided to them by APIs like D3D, OpenGL, and Vulkan which don't use DMA to move the textures. DMA hasn't been used in earnest since before those APIs became common. All of those APIs also support super textures either for sectioning (using segments of a larger image to reduce HDD/SDD load) or sky domes.

Yes, streaming, but most engines that are big on streaming (like UE4) and are of the era where >4 GiB VRAM can be used are also already 64-bit so it's a non-issue. This is where you run into problems with graphics cards that have <4 GiB VRAM because the API is having to shuffle assets between RAM and VRAM which translates to stutter.
 
Developers use the methods provided to them by APIs like D3D, OpenGL, and Vulkan which don't use DMA to move the textures. DMA hasn't been used in earnest since before those APIs became common. All of those APIs also support super textures either for sectioning (using segments of a larger image to reduce HDD/SDD load) or sky domes.
That doesn't prevent said APIs from doing DMA internally.

Yes, streaming, but most engines that are big on streaming (like UE4) and are of the era where >4 GiB VRAM can be used are also already 64-bit so it's a non-issue. This is where you run into problems with graphics cards that have <4 GiB VRAM because the API is having to shuffle assets between RAM and VRAM which translates to stutter.

Streaming is the non-naive way to handle large assets in programming.
 
That doesn't prevent said APIs from doing DMA internally.
But they don't and that's the point. Everything in VRAM flows through RAM.

The argument I made before about 32-bit and VRAM being intrinsically linked is effectively true. Now that the 32-bit barrier is gone, VRAM usage has soared in games that can use it.
 
Last edited:
Back
Top