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.
