Will GPUs with 4GB VRAM age poorly?

Judging by ms's render of the Scorpio, it will have 12gb of ram total. So 9gb usable for games seem reasonable if the same O's reservation is kept. 8gb won't be enough then if 4gb isnt enough now.

 

3GB cards are aging poorly, not all of them though.

Spoiler

 

Doom has settings beyond Ultra that should in theory kill 7970, though.

 

Maybe NVidia's driver for those old cards isn't working correctly?

 

Or Nvidia has put a lot of effort into optimizing for specific games on their hardware at the driver level.

Devs make choices that has to work on all platforms and some of these choices will be suboptimal for Nvidia hardware, some for AMD and Intel. DX12 doesn't allow the same level of intercepting stuff; Substituting buffer layouts/formats and shader code on the fly.

Drivers have always been Nvidia's strong suit.

Cheers

 

I like how my 4 years old HD 7970 OC (which is bascially a R9 280X) inches ahead of the much more modern and with 33% more memory equipped R9 380X and is within striking distance to the lesser Hawaii-based models as well as almost reaching the GTX 970. And of course, how my shiny new, 220-EUR-RX480 is faster than a GTX 980.

 

If he were doing that he would have linked the computerbase benchmarks with the 4GB fury beating even a 1070 by a fair margin.
https://www.computerbase.de/2016-07/doom-vulkan-benchmarks-amd-nvidia/
Regardless the standardized use of ASTC and even procedural texturing will help a lot. NVLink or whatever AMD is using to the CPU/system memory and it's even less of an issue.

 

But as was pointed out in the other thread gamegpu used a setting that precludes Async Compute from working

 

Yes, advanced modern straming techniques help a lot. However, Virtual/Sparse textures or Tiled/Reserved resources (did I miss some extra nomenclature?) are still uncommon in a lot of modern games (we can tanks Terascale and pre-broadwell GPUs for that I guess... plus the lack of DirectX 11.2 support under Windows 7).
If we talk about things like VR +MSSAA bandwidth waste due texture streaming could become a serious issue under multi-GPU.
PS: wasn't 64K the minimum granularity under Windows?

EDIT: there are also game using dynamic details scaling techniques to deal with "small" VRAM pools, like the last couple of Total War (which is the reason I never consider such games as pure benchmark if the related option is enabled).

 

That's exactly what the Game Ready drivers are. Well, the games part. Architectures seems to be a much muddier facet.

 

Software indirection (in virtual texturing) is practically free nowadays. Redlynx Trials games and id software games ran already at locked 60 fps on last gen consoles. Software indirection is just a couple extra ALU. And the indirection texture read is super cache optimal (as 128x128 pixels read the same texel). It is close to 100% L1 hit.

Software indirection also results in tightly packed "physical address space". This is great if you use deferred texturing and need to store the "physical UV" to your g-buffer.

As you said, hardware PRT has also too big page size. 16 KB would be much better. Software indirection doesn't have this problem.

Also regarding to virtual/sparse shadow mapping. You need to refresh the mapping every frame. GPU goes through the depth buffer and determines shadow map page visibility (and mip). Current APIs dont have UpdateTileMappingsIndirect. You can't change the hardware PRT mappings without a CPU roundtrip, and that would either stall the GPU or add one frame of latency -> shadow glitches. Thus software indirection is currently the only possibility.

 

16K and indirect tile update.
This is a good reuqest for Santa Claus living in Redmond

 

I talked with Ola Olsson (his paper: http://www.cse.chalmers.se/~uffe/ClusteredWithShadows.pdf) at Siggraph last year and we discussed about this problem. He was talking about virtual shadow mapping local lights and I had one slide about our sunlight virtual shadow mapping stuff. They use hardware PRT and it stalls everything. Also the page mapping changes are horribly slow on OpenGL. These problems are acceptable for research papers/demos, but you can't afford the stall in real games. Everyone doing research on this topic agrees that indirect page table update is needed. Otherwise hardware PRT loses many use cases.

 

Why? A page fault will force you to load from disk anyway, so where's the heck? Do you talk about dGPU systems with some textures held in CPU RAM?
I do not see exactly the point with HSA -except, of course, if the HDD doesnt have the 64k read sequentially at hand.

The CPU trap triggered by the GPU is causing so much latency to lose a frame? Again, are you talking about windows or consoles?

 

No, I was talking about hardware PRT (tiled resources) API. On PC you don't have any other way to do sparse GPU virtual memory mappings. The page size is 64 KB in PC DirectX. Virtual memory is useful for data streaming, but it is also very useful for sparse resources, such as sparse shadow maps and volumetric data structures (sparse voxels). 64 KB page mapping granularity is too coarse for these purposes.

HDD sector size has no meaning for virtual texturing. All modern virtual texturing systems compress data separately in a different variable bitrate format for HDD (either lossless LZMA style or lossy wavelet/JPG style). Data is transcoded at page load. HDD data chunks do not have 1:1 mapping to GPU pages. Usually HDD pages are grouped in macro pages to reduce seeking.

There is no CPU trap in PC DirectX API. You need to manually put page misses to an append buffer, readback page miss buffer on CPU (next frame) and call UpdateTileMappings to update virtual memory page table. This is acceptable for texture streaming (virtual texturing), but it not acceptable for dynamic GPU generated data, such as sparse (virtual) shadow maps. We need UpdateTileMappingsIndirect API. GPU writes new tile mappings to a UAV and indirect mapping changes mappings accordingly.