• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Why do higher resolutions use more VRAM?

H

hajalie24

[H]ard|Gawd
Joined
Dec 22, 2010
Messages
1,483
I'm trying to understand why. Textures and vertices will stay the same size, since polygon count doesn't increase. The only thing that will change is the frame buffer. 3840*2160*32bit(rgba) = 253MB, if you're using vsync I guess it would have two frame buffers stored so that will take up 500MB. Which is more than 400MB over 1080p (63MB framebuffer). If you use triple buffering then it will take up ~750MB. Edit: Forgot to convert from bits to bytes, I knew that seemed like too much. It's actually ~32MB for 4k and ~8MB for 1080p.

Is it for line and polygon rasterization? Since the distance between the two pixels will be greater now, there is going to be more to sample. But I don't see how this uses more VRAM, since AFIAK you only need to store the endpoints. I can certainly see how it uses more processing power though. Same for MSAA, you're just sampling more points, why does it use more VRAM?

I must be missing something, or the rasterization algorithm is more complicated than that. If someone can explain, or redirect me to where I can find more information about this, that would be great. Thanks.
 
Last edited:
It's been a while since I looked into this, but iirc all the target data structures are just bigger at bigger resolutions. Frame buffer is one of them, but is the last before the frame is output to a monitor. Another example is Z-culling which you want done at the target resolution for maximum quality. My guess on AA is that they do it at the output resolution for pragmatic reasons since the general AA algorithm has edge cases that need to taken care of. The reasons MSAA uses more ram is exactly because it has more points. More points = more data structures :)
 
Forgive me if I over simplify this, but the pixel count plays a direct role in the way textures are stored in memory. Say you are trying to display a picture of something that has 100x100 pixels vs 200x200. There are several factors that come into play when displaying that image at maximum quality. Each pixel is taken into account and is affected by adjacent pixels. A 5x5 grid of pixels would have less variation than a 10x10 one displaying the "same" thing, meaning fewer calculations and less memory buffer. Let's say that grid was trying to display from top left to bottom right, white to black, respectively. In the larger grid, it would introduce more shades (of gray) between white and black to get you to the same place, absolute black. Because of that, the GPU has to calculate more and store more in the memory buffer to provide you with those additional grays. That is why lesser video cards often have to decrease quality to produce better FPS at higher resolutions. At max settings a 10x10 grid of pixels may have 100 different colors, however at medium, there may only be 50 since adjacent pixels could just use the calculations already done by neighboring pixels, giving you a washed out effect, but allowing your lesser GPU to still play the game at a higher framerate.

Newer-gen GPU's will then focus on optimizing problems that were introduced in previous gen cards, by adding instructions to take "shortcuts" (very loosely used) and/or increasing horsepower. This is one of the reasons there are so many different versions of AA. One of the current issues is driving 4k displays. Optimizations that worked for 1080p or 1440p suddenly aren't as effective because there are so many more pixels that must be taken into account...back to the drawing board.

There are of course other factors that come into play. How optimized the game is, how optimized is the engine that the game uses, ie., the tools that you have to work with to write the game. In school there is a term called Big "O" notation, ie., "whats the quickest way to get to the same end result". "n" vs "n^2", for example. You want as close to "n" as possible, without sacrificing anything.

Anyway, I hope that helped. There is a lot of good material out there explaining this in more detail, but often times you have to piece multiple sources together to get a complete understanding.
 
Last edited:
Darakian said:
It's been a while since I looked into this, but iirc all the target data structures are just bigger at bigger resolutions. Frame buffer is one of them, but is the last before the frame is output to a monitor. Another example is Z-culling which you want done at the target resolution for maximum quality. My guess on AA is that they do it at the output resolution for pragmatic reasons since the general AA algorithm has edge cases that need to taken care of. The reasons MSAA uses more ram is exactly because it has more points. More points = more data structures :)
Click to expand...

Thanks, I forgot about the Z buffer.

But the MSAA algorithm I know of doesn't store anything extra based on resolution. If you're using 4xAA, it will sample 4 points in that pixel, and if lets say 3 of the points are a match to be drawn, then the pixel will be drawn with 75% opacity. This doesn't use much more memory, just more calculations. And once you draw the pixel you can reuse the same memory for the next pixel. Is this not correct, then can someone link or describe the MSAA algorithm?

Forgive me if I over simplify this, but the pixel count plays a direct role in the way textures are stored in memory. Say you are trying to display a picture of something that has 100x100 pixels vs 200x200. There are several factors that come into play when displaying that image at maximum quality. Each pixel is taken into account and is affected by adjacent pixels. A 5x5 grid of pixels would have less variation than a 10x10 one displaying the "same" thing, meaning fewer calculations and less memory buffer. Let's say that grid was trying to display from top left to bottom right, white to black, respectively. In the larger grid, it would introduce more shades (of gray) between white and black to get you to the same place, absolute black. Because of that, the GPU has to calculate more and store more in the memory buffer to provide you with those additional grays. That is why lesser video cards often have to decrease quality to produce better FPS at higher resolutions. At max settings a 10x10 grid of pixels may have 100 different colors, however at medium, there may only be 50 since adjacent pixels could just use the calculations already done by neighboring pixels, giving you a washed out effect, but allowing your lesser GPU to still play the game at a higher framerate.
Click to expand...

This seems like a good example of something taking more processing time but not more space, unless I'm understanding it incorrectly. But when you know the amount of pixels, then you know the weight each pixel carries. So a 5x5 grid will have 25 pixels, for black to white, each pixel color will just be incremented by 1/24 from the last one, and you have a nice gradient while using O(1) space.
 
More pixels = more pixel data, simple as that. Each one of those pixels require a chunk of memory to store the 8 or even 10 bit color value it's assigned.
 
Last edited:
Kor said:
More pixels = more pixel data, simple as that. Each one of those pixels require a chunk of memory to store the 8 or ever 10 bit color value it's assigned.
Click to expand...

I already covered that. It takes 8MB for 8 bit color value on 1080p to cover all the pixels, 32MB for 4k.
 
hajalie24 said:
I already covered that. It takes 8MB for 8 bit color value on 1080p to cover all the pixels, 32MB for 4k.
Click to expand...

Now take that same 8-32MB and multiply it for each stage in the rendering pipeline. Each stage takes up extra memory before the frame is produced. The final product is but one of many stored in the buffer.
 
same reason why my new 27 inch monitor came in a bigger box than my 20inch monitor.
 
It would be great if there was a Task Manager app for video cards, to see RAM usage.
 
Kor said:
Now take that same 8-32MB and multiply it for each stage in the rendering pipeline. Each stage takes up extra memory before the frame is produced. The final product is but one of many stored in the buffer.
Click to expand...

This is the correct answer. There are effects buffers, shadow buffers, stencil buffers, z buffers, ping-pong buffers, etc. For a breakdown of ram required for a deferred renderer, bare-minimum, see this post:

http://techreport.com/forums/viewtopic.php?f=3&t=90126#p1182424

Also, don't forget that for 3D, we use 64 bits per-pixel for most shader operations, not 32 bits like in 2D.

TLDR: (and these numbers change depending on the game):

1920x1080 4xMSAA = 187.113MiB

2560x1440 4xMSAA = 316.313MiB

3840x2160 4xMSAA = 685.453MiB

The sizes still scale linearly with resolution, there's just several more buffers than people expect, and they are larger than people expect. Still, assets use the majority of vram.
 
Last edited:
hajalie24 said:
This seems like a good example of something taking more processing time but not more space, unless I'm understanding it incorrectly. But when you know the amount of pixels, then you know the weight each pixel carries. So a 5x5 grid will have 25 pixels, for black to white, each pixel color will just be incremented by 1/24 from the last one, and you have a nice gradient while using O(1) space.
Click to expand...

Which is why I said forgive me if I over simplify it ;) Additional buffers are stacked which start to add up pretty quickly, but pixel data is definitely one of them.
 
Kor said:
Now take that same 8-32MB and multiply it for each stage in the rendering pipeline. Each stage takes up extra memory before the frame is produced. The final product is but one of many stored in the buffer.
Click to expand...

defaultluser said:
This is the correct answer. There are effects buffers, shadow buffers, stencil buffers, z buffers, ping-pong buffers, etc. For a breakdown of ram required for a deferred renderer, bare-minimum, see this post:

http://techreport.com/forums/viewtopic.php?f=3&t=90126#p1182424

Also, don't forget that for 3D, we use 64 bits per-pixel for most shader operations, not 32 bits like in 2D.

TLDR: (and these numbers change depending on the game):

1920x1080 4xMSAA = 187.113MiB

2560x1440 4xMSAA = 316.313MiB

3840x2160 4xMSAA = 685.453MiB

The sizes still scale linearly with resolution, there's just several more buffers than people expect, and they are larger than people expect. Still, assets use the majority of vram.
Click to expand...


Thanks. Especially for that link, that was a great explanation. And if I'm reading that correctly it seems like MSAA could really use a lot of VRAM for games that use multiple back buffers.
 
hajalie24 said:
Thanks. Especially for that link, that was a great explanation. And if I'm reading that correctly it seems like MSAA could really use a lot of VRAM for games that use multiple back buffers.
Click to expand...

Yup, it's not free.

But it was an incredible breakthrough compared to SSAA, which uses a whole lot more ram and resources.

Much like FXAA/SMAA/MLAA are incredible compared to MSAA. As time marches on, we find new ways to remove artifacts for less memory.
 
defaultluser said:
That my friend is what Excel was invented for :D

You can be sure he didn't do these calculations more than once.
Click to expand...

Pretty sure he means the resulting numbers are scary, not that the calculations themselves are scary.
 
I use HWiNFO and Rivatuner so I get info on each CPU core (have 8) all memory( ram and pagefile/virtual) GPU temps and usage( memory included) Board temps voltages... All the info I may need streaming constantly.

(WARNING) You can get VRM temp stats with this but the first R9-290 I had died within 2 hours, had weird usage issues varying clocks and voltages. Seem the varying was caused by the monitoring. LIKELY this is a by product of my setup alone because I have seen no other with the same issue. So test carefully if you want to have VRM monitoring with HWiNFO.
 
You must log in or register to reply here.
Back
Top