I want to make RBG texture 256512512 I had try to make proxy texture and everything is ok. But result is that my texture is black (not white like usualy when driver is not posible to make texture)
I had try to change texture color dept in driver OpenGL options and I it was funny.
when it is at 16bit, texture size 512512128 is ok,512512256 is black,
when it is 32bit, 512512128 is black and 512512256 is white
when it use desktop color depth it works always like when it is on 32bit. Also when is desktop color dept at 16bit
Did someone know what is the problem what Im doing wrong.
thanks
I had a problem with big 3D textures on my GF4 Ti4400. Anything over a certain size (but still smaller than the 128Mb) was not working.
I found the problem was the BIOS settings on my machine, which was only set to map out a 64Mb aperture for AGP. That meant that only part of the GF4 texture memory got mapped with the above result.
I changed the AGP aperture setting to 256Mb following advice on (I think) NVidia’s site and all works fine now.
I’ve seen a bug where extremely large textures (e.g. 4096x4096 2D textures with mipmaps) turn black if the card runs out of memory for them. What you’re seeing is probably the same thing. The bug has been fixed in Detonator 50.12, which will report GL_OUT_OF_MEMORY so you can handle the situation.
– Tom
[This message has been edited by Tom Nuydens (edited 06-25-2003).]
A texture has to fit completely into graphics memory. It shares the memory with the framebuffer, display lists, pbuffers, etc.
So if you have 128 MB memory:
512x512x128x2 = 64 MB - OK
512x512x256x2 = 128 MB - error
512x512x128x4 = 128 MB - error
512x512x256x4 = 256 MB - error
So every thing is as expected.
Tom: is it true ? will the driver eventually report “out of memory” ? Where did you get that information ? Where did you get that driver ? I only saw a 64 bit version of 50.x drivers.
BTW: If you really require to render large textures that do not fit into graphics memory you can always subdivide the texture into tiles/bricks and render those parts individually. Of course, you will be limited to the AGP memory bandwidth limit …
Note, that tiles/bricks have to overlap by one texel to fix filtering/interpolation.
I’m just repeating here what NVIDIA told me when I reported this bug, namely that the fix will appear in version 50.12. I don’t actually have these drivers yet.
KlausE, everything is currently not “as expected” – if a texture is too big to fit in graphics memory, the driver should report GL_OUT_OF_MEMORY and disable the texture unit. The proxy mechanism should also be capable of detecting this case, so that you can respond appropriately, e.g. by shrinking the texture.
BTW, note that this not only applies to textures that are too large to fit in graphics memory – it can also happen when making heavy use of multitexturing. If all currently bound textures can’t fit on the card together, the same problem will occur (the ones that won’t fit will turn black). I don’t know what you would do in this case, as the proxy mechanism would presumably tell you that each of the textures is okay, without knowing that you intend to use them all together.
Tom: Yes, right … it is not as expected. But that never worked correctly and i did not expect a fix until we get real texture memory management in OGL 2.0
It’s expected that it does not work, it is not expected that it does not report an error.
so I had try to make texture with internal format GL_LUMINANCE16 and size 512x512x256 works but RGB with this size didnt work when texture color depth is 16bit.
512^3 is also black.
Yes, right … it is not as expected. But that never worked correctly and i did not expect a fix until we get real texture memory management in OGL 2.0