> A window resize does this? I’ve done some graphics development in Linux with large textures and window resizes using NVIDIA cards and never had that problem.
I’m pretty sure that I’m doing nothing special, a simple (Qt based) app and really lots of 3D textures that cannot be held completely in the graphics RAM, and there you have it. I don’t consider it a good solution to do the texture memory management manually by using lots of glTexSubImage calls since that would certainly be a performace problem.
> It sounds like a memory management bug, although a larger window requires more graphics memory and that could potentially start lots of memory paging that would grind performance to a halt.
The system doesn’t halt, but the renderer gets really sloooow. Nevertheless the renderer continues to work, a clear sign for a kind of software fallback.
> Some nasty things can happen with graphics memory management
I see, but the driver always knows how much graphics mem is available, doesn’t it. So, when a window resize requests a certain amount of mem the textures could be easily rearranged.
> It’s never a good idea to oversubscribe graphics memory and even worse to use up your GART mapped memory but the drivers should handle this or report an error.
There is no error report. I always check for errors after each gl call.
> Software fallback is a perfectly legitimate recourse but still probably a bug in your case. Slow performance can be caused by things other than software rendering.
How can I find out if I have a sw fallback? There’s no way in GL to find out, right?
> You might want to increase your AGP GART mapped memory in the BIOS and see if that helps.
I’ll try. But the “aperture” is usually limited, too. Btw. is it legal in GL to create more textures than the graphics mem plus AGP aperture? I think I’ll have situations where this will be the case. The driver could then simple swap data between agp and “normal” memory, in AFAIR it does.