Will GPUs with 4GB VRAM age poorly?

Watch Dog 2: PC graphics performance benchmark review

http://www.guru3d.com/articles_pages/watch_dog_2_pc_graphics_performance_benchmark_review,1.html

 

I think we need to see VRAM usage at Medium settings. Are these modern titles with higher quality assets (now that consoles get to also have decent assets), proving that 4Gb VRAM GPUs simply need to lower their details settings?

 

You need 980 Ti, Titan or 1070/1089 to reach 60 fps on Ultra settings at 1080p! Ultra is definitely not something that is targeting 4 GB users.

My point stands: 4 GB isn't a problem since these mid tier cards can't even run ultra settings fast enough (60 fps minimum). You need to drop to high settings -> significant drop in VRAM usage. Unfortunately this benchmark includes memory consumption graph only for ultra settings. It's odd that reviewers seem to be nowadays considering ultra as the standard setting. Even if you need a 1200$ card to reach 60 fps at 1440p.

 

Yeah I ran into that with Dishonored 2 as well. 4GB GPU + 8GB system RAM will be almost entirely used at times. I ran into some major performance degradation after playing the game for awhile and it would reach this max utilization.

Installing an 8GB GPU reduced system RAM usage by about 1GB.

 

I think the main issue is the 980 used to be the GPU for ultra setting and then 2016 happened and it was no longer. The shift was swift, sudden. Even by GPU standards, this was fast. This is some 1990s level of shit going on there. People aren't used to it. They've forgotten(Or, in the case of many, many of them, never knew. I know because I've read a fuckton, but I'm sure a lot of my generation or younger don't know. For the record, I'm a few months into 29. This is the age group I'm referring to).

Edit: Lack of comma fixed as well as adding a bit of text to flesh this out a bit more.

 

What I am trying to figure out is whether this is a pure GPU memory limit, or a problem related to insufficient total memory (GPU + system RAM). Modern PC games tend to overcommit graphics memory heavily. The remainder is kept on system RAM (*). This system works pretty well as long as you have plenty of system RAM to spare, but obviously it becomes a problem if you haven't.

By reading the discussion, it seems to me that upgrade from 8 GB -> 16 GB of system RAM is a higher priority for gamers than switching from 4 GB -> 8 GB graphics card. I personally have 32 GB of system RAM, so I have no clue about the stuttering issues present on systems with lower system RAM amounts.

(*) Vulkan and DX12 are the exceptions. Overcommitment is not possible with these APIs. Developer has to write custom code to move textures in/out of GPU memory. Asynchronous copy queues are the right way to do this. It seems that developers haven't yet managed to beat DirectX 11 drivers in GPU memory efficiency with their custom Vulkan and DX12 memory managers. I would guess that most devs are using modified versions of their console resource management on Vulkan and DX12 PC versions. These systems are written for UMA systems with a single shared memory pool, with the goal of minimum total memory usage (data is loaded directly to GPU memory). However on PC you could spend a little bit more system RAM to make things easier on GPU side. Robust management of separate memory pools (PC) and transfers between them require lots of extra logic. I wouldn't expect to see major improvements until we see engines designed from ground up to Vulkan / DX12 resource management model. This can only happen after it is commercially viable to drop DX11 support.

In the long run Vulkan and DX12 allow reduced GPU memory usage, as these APIs allow placing multiple resources on top of each other in memory. You can for example overlap your post processing (HDR) buffers with your g-buffers in memory. The gains are biggest at high resolutions (4K). You can also pack some data tighter in memory (DX11 resources have large alignment). Console games have done optimizations like this for long time already (very common with last gen consoles that only had 512 MB of memory). Obviously we aren't there yet. Currently DX12 and Vulkan ports consume more GPU memory than alternatives on PC.

 

Thanks for posting here in this thread sebbi. You posts surely are very enlightening!

But WRT streaming systems I still think you are talking about what can be done, while some of your colleagues just do other things - maybe because they don't get budgetting for better systems on PCs (which I imagine must be redesigned from an UMA like on consoles and thus do not come for free on recompile. The vague examples I mentioned are observed on our normal testing systems which have plenty of RAM (32 GiByte to be exact). So if we see popping there, developers probably do not run out ot main memory, but rather do use the SSD (not HDD in our case) as direct source. Which would further reinforce your point that streaming works, but must be properly implemented.

Don't get me wrong, I see reason in your postings and there are games out there that do show it's possible. But a lot of games otoh do not - which makes people prepare for those worst cases with large amounts of memories.

 

I think we are still under transition period. Devs have just maxed out current gen console memory budgets (at 1080p). 1440p and 4K displays are starting to get popular among PC gamers. Now again the consoles are the limiting platform -> devs experiment new high end effects and settings on PC -> crazy ultra settings. Both Nvidia
and AMD released their first consumer cards with more than 4 GB memory just one year ago (2015 summer). 980 Ti with 6 GB and 390/390X with 8 GB. I'd guess many devs upgraded to 980 Ti and now we are seeing the impact. It seems that many studios need to improve their streaming technologies to enable smooth scaling from entry level (2 GB) to high end (12 GB). This problem didn't exist year ago, so it is understandable that some engines show various issues.

 

I would assume many users are on 8GB, most of them on DDR3, some on DDR4. (some of them with a couple 4GB sticks in a motherboard with two slots). An awful lot of Sandy Bridge to Haswell machines and some earlier ones.
I am sure it's a simple matter of updating the "conventional wisdom" but it was not very long ago that people were saying "4GB for browsing, 8GB for games, 16GB is useless"

(money exchange rates and RAM chip prices change all the time, so I'm seeing quite higher prices at my point in time and space. Otherwise even for non-gaming, non-multimedia I agree you'd better have more RAM than not)

 

I know. My friend had to convince me a lot to get more than 16 GB to my home computer. And 16 GB of DDR4 is just 80$ nowadays. Memory is dirt cheap. Unfortunately devs seem to assume that everyone has bought enough of this dirt cheap memory -> problems with 8 GB.

 

Watch_Dogs 2 touts HBAO+ implementation. The reconstruction hampers the effect? Is this something you've personally seen or from videos/screenshots?

 

It's not the reconstruction, but the reduction in samples. It seems like it was a lot more obvious in rainbow six though.

 

It is great to see devs finally starting to use temporal reconstruction. Papers have existing for ages. Checkerboard technique in particular is working very well. R6 Siege was the first to use it, but now it is powering 4K rendeing in many PS4 Pro games. Hopefully devs allow checkerboard mode also on PC. I just got a 4K monitor. 4K at 60 fps is definitely achievable with checkerboard rendering (cost is similar to 1440p). Good temporal checkerboard implementation is hard to distinguish from "native" 4K.

4K checkerboard render targets consume only 50% memory (similar to 1440p). However texture streaming still need to load as detailed mip levels as native 4K. Checkerboard has negative mip bias (actually custom gradient calc). When camera is stationary the result is identical to native 4K.

 

http://images.nvidia.com/geforce-co...comparison-001-off-vs-temporal-filtering.html

 

Clearly shows it there as well.

 

I don't think it's the reconstruction that messes up the SSAO implementation. I would guess the lower resolution intermediate buffers (with 2xMSAA jittered samples) causes the SSAO implementation to misbehave. I don't know what kind of changes to the SSAO filter they implemented in order to support the jittered sample pattern properly. If they simply flatten the 2x2 lower res 2xMSAA depth buffer as 2x1 lower resolution intermediate buffer and feed that to SSAO, then the result will be different. And that still requires changes to SSAO algorithm, as the pixels are anamorphic. Checkerboarding is not easy to implement perfectly. Lots of small details that need to be considered.