Jump to content

  • Log In with Google      Sign In   
  • Create Account

Calculate GPU memory usage


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 __SKYe   Members   -  Reputation: 1099

Like
0Likes
Like

Posted 29 December 2013 - 07:44 AM

So, i'm thinking of calculating the VRAM in use.

 

Now, i don't intend to track every single byte in the VRAM (nor do i think it's possible), i was just thinking of keeping track of how much memory

I upload to the GPU, to get an estimate of the VRAM that is in use (by keeping track of the amount of memory textures, VBOs,buffers, etc occupy).

 

Of course i'd have to keep in mind packing, compression, etc. My question is mostly about the color/depth/stencil/etc buffers.

 

 

Say i create a window, single buffered, with a 32-bit (RGBA) color depth and a 16-bit depth buffer.

 

I know that the color buffer occupies 4 bytes per pixel, and has the same size as the window (say 800x600).

The depth buffer occupies 2 bytes per pixel and also has has the same size as the window.

 

My first question would be. If i switch to fullscreen mode with a bigger resolution (say 1280x800), am i correct to assume that they are expanded to match the new window size?

And if i return to windowed mode again, assuming the buffers are, once again, resized to match the window size, to the memory the buffers occupy in the VRAM actually shrinks, or is just a part of the memory that was used for the larger (fullscreen) size is unused?

 

Also, for double buffering, the window requires 2 color buffers, basically doubling the memory needed for the color buffers, right?

I also assume that using double buffering and support for stereoscopic 3D means 4 color buffers (back left & right, front left & right).

 

Another question would be, does the stencil buffer uses it's own memory, or is it shared with another buffer (say the depth buffer)?

 

Also, i've read somewhere that multisample requires a buffer per sample (say a 4x Multisample would require 4 buffers). If anyone could enlighten me at this, i'd appreciate it very much.

 

I'm nol yet accounting for user created buffers (like geometry buffers user for deferred shading, or a custom, floating point, depth buffer for HDR).

 

As a last note, is it correct to assume that all this things that can be created by the graphics API (OpenGL in this case) reside on the VRAM, or are there exceptions?

 

If something is not clear, then i'll be happy to explain.

 

Thanks in advance.


Edited by __SKYe, 29 December 2013 - 07:47 AM.


Sponsor:

#2 3TATUK2   Members   -  Reputation: 730

Like
0Likes
Like

Posted 29 December 2013 - 07:45 AM

Just use something like MSI Afterburner or GPU-Z ?



#3 __SKYe   Members   -  Reputation: 1099

Like
0Likes
Like

Posted 29 December 2013 - 08:48 AM

Oh no, i'm talking about calculating the amount of VRAM used, from within the game/application.

Something like what you do with your custom memory manager to keep track of how much RAM you've allocated, and where allocations are going.

 

GPU-Z is an offline utility to get GPU information right?


Edited by __SKYe, 29 December 2013 - 08:50 AM.


#4 Vortez   Crossbones+   -  Reputation: 2704

Like
0Likes
Like

Posted 29 December 2013 - 09:23 AM

Take a look at this post.



#5 __SKYe   Members   -  Reputation: 1099

Like
0Likes
Like

Posted 29 December 2013 - 10:01 AM

Thanks, that's helpful to know if you're within VRAM budget.

 

But while it is helpful to know the amount of memory used, it still won't help much with what i'm after.

 

You see, what i mean to do is basically to keep track of how much memory i allocate for the various types of data that resides in the VRAM.

This can be textures, vertex/normal/texcoords data, the color/depth/stencil buffers, etc.

 

Again, i don't mean to track every single byte of memory that is in the GPU, i just want to keep an "in-house" estimate of the VRAM used.

 

As an example, think of how you would create your own memory (normal RAM) tracker, to get stats like:

 

General:   2312083KB

Audio:         195421KB

MAP:       29383467KB

 

etc...

 

And the VRAM equivalent could be:

 

Color Buffers:     503918214KB

Depth Buffer:        78216928KB

Textures:        23487654303KB

Geometry:          489279345KB

 

etc...

 

Note that i don't mean to query the GPU for the amount of data i sent, or the memory in use.

What i'd do is to calculate the amount of memory a resource would use when i create/upload it in/to the GPU.

 

Again, image i load a R8G8B8A8 128x128 (uncompressed) texture from disk, and upload it to the GPU. Here i'd calculate the memory required for the texture (which would be 128*128*4 -- assuming the internal storage is also RGBA, etc) and perhaps add it to a counter of the total texture memory used.

 

I know that the GPU can remove textures from the VRAM if you upload more textures than the available memory, among other issue, so it's just an estimate.

 

Sorry if the explanation isn't clear.

 

Thanks again.



#6 Matias Goldberg   Crossbones+   -  Reputation: 3697

Like
3Likes
Like

Posted 29 December 2013 - 11:56 AM

The logic behind all your reasoning is correct.

 

However the driver and hw internals can screw your calculations completely.

 

Even though you request one Front buffer and 2 backbuffers, the GPU may actually internally have like 3 copies of them for pipelining and avoiding stalls, etc; and you have no idea to know what the driver is doing behind your back (that's the main point about the yet-unreleased Mantle, the API doesn't do stuff behind your back).

The duplication thing may even further if the GPU is in Crossfire/SLI mode.

 

For example, in many GeForce architectures (actually, AFAIK all of them) if you request an FBO of Float R16; internally the driver will use a Float F32 since their GPUs don't natively support R16 (but this may change in the future, and you don't always know this kind of stuff; this is only known because F32/F16 are both a very used and abused format, and NVIDIA has stated this explicitly many times in their GDC courses).

 

As for 32-bit colour framebuffers with 16-bit depth buffers, forget about it. It's been a very long time since I've seen a GPU that can mix colour and depth buffers of different bitdepths (use all 16-bit or all 32-bit). It either fails or internally just uses the largest bpp.

 

Same issues with the stencil buffer: In some architectures it will be shared with the depth buffer, i.e. 24 bits for the depth, 8 bits for stencil.

In other archs, they're separate (32 for depth or 24 for depth + 8 unused, and then another buffer with 8 for stencil)

 

As for MSAA, this will enlighten you (basically, 4x antialiasing = 4x the resolution of a colour and depth buffer; plus a buffer at 1x resolution to resolve. How many resolve buffer depends on how you tell the card to do it).

 

So bottom line, you can calculate your "theoretical" requirement, but the actual, real number in a particular system is completely dependent on the driver and the GPU architecture.



#7 __SKYe   Members   -  Reputation: 1099

Like
0Likes
Like

Posted 30 December 2013 - 12:10 AM

Well, then i guess this really ins't as simple as i thought.

 

Many thanks to you all.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS