video ram on graphics card
Author
1) Lets say my graphics card only has 512 MB of VRAM and I've used up almost all of it (by "pushing" a bunch of textures onto it) and I go ahead and send another texture data to the graphics card (thereby sending more than 512 MB of data to the VRAM), what happens to the existing data and the one I've just sent to the graphics card? Does the graphics card remove the oldest texture data to make room for the new one?
2) Is there any way to check how much video ram is left/available on the graphics card? I want to manually remove (unused) textures if there isn't enough VRAM for new incoming textures.
Thanks.
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
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.
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.
Author
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?
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.
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.
Author
"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?
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_portDon'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.
"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?
Also consider that many systems (particularly embedded systems, of those with integrated GPUs) don't have VRAM, instead sharing a chunk of system memory.
Author
Quote:Original post by swiftcoderQuote:Original post by 16bit_portDon'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.
"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?
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_portNeither question is answerable in the way you are looking for.
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?
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement