I have found that when the GPU overheats, a program will switch from OpenGL rendering to a software fallback. More interestingly, I’ve found that there’s a difference in semantics between software and hardware support.
My FBO class checks for errors after all the setup was completed (but before any render targets had been added). When rendering with GPU mode, this works fine. However, with the software fallback, I get GL_FRAMEBUFFER_UNSUPPORTED. This code is fairly robust and I’ve used it for years without incident–the problem only seems to occur when a software fallback takes place. I’m assuming this difference in behavior is unintentional. Does anyone know for sure?
Um, when the GPU overheats, you have bigger problems to deal with. An overheating GPU is generally not something you can plan for or deal with in software.
In general, if you get GL_FRAMEBUFFER_UNSUPPORTED, the only thing you can do about it is try a different FBO configuration.
When a GPU gets too hot, the driver will switch to a software fallback until the GPU is ready again, preventing damage. The “software” in this case is the driver’s software renderer–not my software that I’m writing.
Yes; initially, I thought it was my code, but after examining the spec., it shouldn’t be giving such an error. There is a known bug with NVIDIA drivers that causes them to give GL_FRAMEBUFFER_UNSUPPORTED when they should have given GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT or similar–but not for a case where there’s no attachment whatsoever.
Anyway, the error only occurs when the driver is using the software fallback–a discrepancy, and also one I don’t think is consistent with the spec.
Did you see a change in GL_VENDOR GL_VERSION GL_RENDERER ?
Because for example microsoft GL software stack is really basic and certainly does not support FBO.
The “software” in this case is the driver’s software renderer–not my software that I’m writing.
I know that. I’m saying that there’s nothing you can do to compensate for it in your code.
Also, I’ve never heard of a driver actually reverting to software rendering within the same context. Not for something like GPU overheating. They’re more likely to just severely down-clock the GPU. Are you sure that’s the reason why this is happening?
Yes; initially, I thought it was my code, but after examining the spec., it shouldn’t be giving such an error.
Why do you say that? In general, implementations are allowed to give that error for any reason they want. Are you using GL 3.0+ combined with the required formats?
No, but it would make sense. I’ve only observed this behavior when performance is drastically reduced (and things like color and point size get messed up too).
Going from here, they can return it when “they do not support some combination of image formats for the attached images”. Similarly, from here, even with NVIDIA’s driver issue, it shouldn’t be giving such an error when there isn’t an image attached whatsoever. In fact (first link), if there isn’t an image attached, if anything the implementation should give GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT.
Thanks,
I’ve watched overheating GF8600 and GTX275 continue running - at about 4-5% performance, until they cool down. (fans were off) They definitely weren’t switching to software rendering. As were running at 2-10fps such scenes scenes, that in software rendering (settings enabled via nvemulate) run at 0.05fps.
This was with drivers before the 26x.x+ series .
Check if “multithreading optimizations” are set to Auto, in nv control-panel. They sometimes cause funky errors/lockups. Set them to disabled or enabled.