Tuesday, December 25th 2018

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

NVIDIA drew consumer ire for differentiating its GeForce GTX 1060 into two variants based on memory, the GTX 1060 3 GB and GTX 1060 6 GB, with the two also featuring different GPU core-configurations. The company plans to double-down - or should we say, triple-down - on its sub-branding shenanigans with the upcoming GeForce RTX 2060. According to VideoCardz, citing a GIGABYTE leak about regulatory filings, NVIDIA could be carving out not two, but six variants of the RTX 2060!

There are at least two parameters that differentiate the six (that we know of anyway): memory size and memory type. There are three memory sizes, 3 GB, 4 GB, and 6 GB. Each of the three memory sizes come in two memory types, the latest GDDR6 and the older GDDR5. Based on the six RTX 2060 variants, GIGABYTE could launch up to thirty nine SKUs. When you add up similar SKU counts from NVIDIA's other AIC partners, there could be upward of 300 RTX 2060 graphics card models to choose from. It won't surprise us if in addition to memory size and type, GPU core-configurations also vary between the six RTX 2060 variants compounding consumer confusion. The 12 nm "TU106" silicon already has "A" and "non-A" ASIC classes, so there could be as many as twelve new device IDs in all! The GeForce RTX 2060 is expected to debut in January 2019.
Source: VideoCardz
Add your own comment

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

#226
FordGT90Concept
"I go fast!1!11!1!"
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.
Posted on Reply
#227
bug
FordGT90Concept, post: 3974924, member: 60463"
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.
Posted on Reply
#228
FordGT90Concept
"I go fast!1!11!1!"
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.
Posted on Reply
#229
bug
FordGT90Concept, post: 3975139, member: 60463"
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.

FordGT90Concept, post: 3975139, member: 60463"
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.
Posted on Reply
#230
FordGT90Concept
"I go fast!1!11!1!"
bug, post: 3975147, member: 157434"
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.
Posted on Reply
Add your own comment