video ram on graphics card

That is handled by the driver and it depends what graphics API you use. With GL, the driver moves texture in and out of VRAM automatically.

Not sure about the answer by VMan. My experience is with DX9. I stopped using low level APIs after that so take this very lightly.

a. Loading will fail. It is possible you find the driver return an error code related to an out of memory error. Keep in mind that not only textures will fill our memory, vertices may also take video memory.
In this case the best approach is creating a texture/mesh manager. In my old engine I had a base common class with a timer. Whenever I needed a texture loaded I requested my manager to load the resource. The manager was able to identify the type of resource and return an appropriate pointer to the loaded resource.
Every resource loaded this way was timestamped. Also, any resource used by any process (rendering or whatever) updated this timestamp. This timestamp allows the manager to make some usage decisions like i.e. when you load a new texture and there is no more space in vram then the manager was able to search the least used resources (the ones not used for a while) and unloaded them to system ram keeping them dormant until required. Then it got enough memory to load your requested texture.
The texture manager is a nice way to control your video ram.

2. There is, but you really shouldn't use it. The reason is that your game should be able to run in any configuration and your target may have less memory than you. Also drivers work in different way so even when another card has the same amount of ram doesn't mean it will behave the same.
Finally, having some available memory doesn't mean it is contiguous memory so the texture loading may fail anyway even when the driver reports enough free memory.

Luck!
Guimo

1) As V-man said.

2) No. VRAM is a virtualized resource. It is entirely managed by the graphics driver and/or the OS. It's not even guaranteed to lie entirely on the graphics card. Depending on architecture, the driver/OS can, for example, map in parts of your system memory in addition to onboard VRAM.

The usual way is to push as many resources as you need, and simply benchmark the game. Provide a simple quality selection to the user, so that he can switch to lower resolution textures if he isn't satisfied with the framerate.

I think it'll clear up some of the confusion I have if I have a better understanding of what's going on internally.

From what you guys have told me and what I've learned after searching around, this is what I've come to understand of how texture data is being processed by the graphics card (at least with OpenGL): glTexImage2D creates a duplicate of the texture data and places in RAM (and is marked by OpenGL to use by a previous glGenTexture call). Then later on in the program, a glBindTexture call moves the texture data to VRAM, and then after graphics card done rendering that texture (signaled by another glBindTexture), it moves it out of VRAM?

Can anyone validate or correct this?

glTexImage2D will indeed make an internal copy of the texture data you provided. Where this copy ends up, in system RAM, in VRAM, in PCIe mapped memory, etc, is only known to the driver. What is important for you, is that from this point on, the ownership of the copied data has moved to the driver. You can delete your own copy of the data you provided.

Also from this point onwards, you have no way of knowing anymore where the internal copy of the data is stored and how it is managed. The driver can basically do whatever it pleases with it internally, so to guarantee optimal rendering performance. For all that you know, it could even be partially in mapped system RAM and partially in VRAM.

glBindTexture doesn't move anything. It's just a semantic call that tells OpenGL that you'd like to use the texture on a certain unit (which will then in turn be bound to a sampler in a shader). It doesn't say anything about how texture memory is managed. All that is completely transparent. Moving textures in and out of VRAM can happen at any time, whenever the driver or OS feels like it. It is completely out of your direct control.

"Moving textures in and out of VRAM can happen at any time, whenever the driver or OS feels like it." seems a little random and vague to me, there has to be a reason or a purpose for sending texture to VRAM by the driver? Is it whenever a texture matrix is being applied onto a texture or when it needs to be rendered?

And then it stays in VRAM until the driver decides to move it out even if it's done using that texture?

Quote:

Original post by 16bit_port "Moving textures in and out of VRAM can happen at any time, whenever the driver or OS feels like it." seems a little random and vague to me, there has to be a reason or a purpose for sending texture to VRAM by the driver? Is it whenever a texture matrix is being applied onto a texture or when it needs to be rendered? And then it stays in VRAM until the driver decides to move it out even if it's done using that texture?

Don't forget that many programs may be attempting to use graphics memory, and each may wish to use more memory than is available. Thus the driver handles moving data in and out of VRAM as necessary, to ensure that performance is maintained.

Also consider that many systems (particularly embedded systems, of those with integrated GPUs) don't have VRAM, instead sharing a chunk of system memory.

Quote:

Original post by swiftcoder Quote: Original post by 16bit_port "Moving textures in and out of VRAM can happen at any time, whenever the driver or OS feels like it." seems a little random and vague to me, there has to be a reason or a purpose for sending texture to VRAM by the driver? Is it whenever a texture matrix is being applied onto a texture or when it needs to be rendered? And then it stays in VRAM until the driver decides to move it out even if it's done using that texture? Don't forget that many programs may be attempting to use graphics memory, and each may wish to use more memory than is available. Thus the driver handles moving data in and out of VRAM as necessary, to ensure that performance is maintained. Also consider that many systems (particularly embedded systems, of those with integrated GPUs) don't have VRAM, instead sharing a chunk of system memory.

Thanks for the extra information, but questions still haven't been answered (at least not directly =P). So I take that as a yes to both questions and that it applies to shader programs as well?

Quote:

Original post by 16bit_port Thanks for the extra information, but questions still haven't been answered (at least not directly =P). So I take that as a yes to both questions and that it applies to shader programs as well?

Neither question is answerable in the way you are looking for.

Rest assured that by the time you issue a draw call (i.e. glDrawElements), the necessary shaders and textures will be bound. Whether those shaders and textures are in main memory or VRAM at that point is for the driver (and the driver alone) to know.

I read about half of the replies. Like everyone has said, nobody really knows. I would assume that most cards can swap between VRAM and PC RAM if the card gets full.

1.) When you call glBindTexture, you are not moving textures between the PC RAM and VRAM. Once the texture is stored on the video card, it is going to stay there (unless you over-fill VRAM).

Quote:

glBindTexture doesn't move anything.

2.) glBindTexture is actually moving the texture from normal VRAM to a texture-unit on the video card. There is a thing called "Texture-Bandwidth" basically like a CPU cache. You want your texture that is being accessed right now, to be in fast-cache memory. This is why DXT compression is good because it keeps the bandwidth down when you bind textures to the faster cache-like VRAM.

Thanks everybody.

Quote:

Original post by dpadam450 I read about half of the replies. Like everyone has said, nobody really knows. I would assume that most cards can swap between VRAM and PC RAM if the card gets full. 1.) When you call glBindTexture, you are not moving textures between the PC RAM and VRAM. Once the texture is stored on the video card, it is going to stay there (unless you over-fill VRAM).

Slightly simplified, but correct.

Quote:

Quote: glBindTexture doesn't move anything. 2.) glBindTexture is actually moving the texture from normal VRAM to a texture-unit on the video card. There is a thing called "Texture-Bandwidth" basically like a CPU cache. You want your texture that is being accessed right now, to be in fast-cache memory. This is why DXT compression is good because it keeps the bandwidth down when you bind textures to the faster cache-like VRAM.

Nope, Yann is correct: glBindTexture doesn't move anything, it merely binds the texture id to a texture sampler. The actual texture data isn't touched until the GPU starts reading from that sampler (and real bandwidth usage depends on sampler state, i.e. filtering type, mip-mapping and bias). Consider this: if you bind a texture but don't render any object with it, will texture bandwidth be used up? The answer is no: you'll use up a small amount of CPU time and bus bandwidth (for state change / validation and command submission, respectively), but you won't use up any VRAM bandwidth at all.

Any given texture may reside in VRAM, system memory on any combination of the two, according to what the driver/OS think is best right now. Since VRAM (if it exists) will always be shared among many programs and will always contain shaders, buffers and a lot of stuff other than textures, it is evident that there's no way to know whether a given texture will be "resident" at any given point in time. As Yann said, the correct approach is to make indirect measurements (, i.e. keep adding textures and see when performance starts dropping) and provide different quality settings.

Quote:

Lets say my graphics card only has 512 MB of VRAM

Quote:

Original post by 16bit_port "Moving textures in and out of VRAM can happen at any time, whenever the driver or OS feels like it." seems a little random and vague to me, there has to be a reason or a purpose for sending texture to VRAM by the driver? Is it whenever a texture matrix is being applied onto a texture or when it needs to be rendered? And then it stays in VRAM until the driver decides to move it out even if it's done using that texture?

The answer to that question depends on many factors. In general a resource is moved to VRAM (if necessary, most hardware can texture from system memory and some can render to it) when it's needed, i.e. when you issue a draw command (or more accurately, then the driver's command buffer is flushed). A resource is generally moved out when the driver needs to make space for other resources being used by you or another program. Sometimes it's moved out because the CPU needs access to it. That's about as general an answer as you will get.

Quote:

Original post by zedz Quote: Lets say my graphics card only has 512 MB of VRAM

There's definetly something very wrong here (especially for somebody which is 16bit).