This is no more a problem than having a CPU run a computationally intensive test that doesn't do anything. GPUs have no problem rendering excess frames, lots of excess frames, and simply not making any real use of them. This is not putting your car in neutral and laying on the gas, it is a meaningless comparison. There would most certainly be a class action suit alleging that the engine was defective by design. Imagine the outrage people might feel if the engine's design limits could be exceeded just cruising down the highway and the first sign of it was that the engine just stops running and never starts again. Unless you're stupid enough to ignore that and keep pushing, the engine suffers no actual damage. Note how in the inevitable car analogy, there are warning lights and significant physical warning signs (such as steam pouring out of the engine compartment to let you know you have exceeded the engine's design capabilities.
Not everything is designed to operate at 100% duty cycle, but in those cases, the duty cycle is well documented and there are usually mechanisms in place to prevent actual damage if the limits are exceeded. Proper engineering includes appropriate margins for error to deal with the real world including things getting dirty and not being put together perfectly. If you do that for too long eventually it will burn out.
When your comp starts or when you do specific things with an application they can run with all of it's parts at full power, but only for a little while. When driving a car you can 'floor it' for a few seconds, but if you left it that way your engine would eventually overheat, if you've ever gotten stuck in the snow or on ice you'll know what I'm talking about. That's a problem that the card will render a scene to look correct even if you treat it badly, so you can sort of plod through development like that, but you shouldn't assume that the uncleaned 3 year old system one of your customers has will be as pristine as your development machines. One of the things here is to do a better job of controlling what's being sent to the card in the first place (BSP trees for example). The other is basically constantly feed the card as much data as possible (some beta builds of STO and early release had this problem), that was basically a problem of not being able to fit a whole area/level in memory, or not wanting to cause a load screen, so you're maxing out your bandwidth to push data to the card, while at the same time letting the player fly around and shoot stuff (and said stuff shoot back). One is the 'draw a simple scene as fast as possible' scenario in SC so cap the framerate at something like 120.
This sort of problem happens a couple of ways. Lots of boards have a northbridge fan that sits directly above the (first) gpu nowdays.Īs a developer there's a bit you can, and should be doing to prevent this sort of thing.
The PSU needs to be able to feed enough juice to the card, the case needs to be properly ventilated (and ideally cleaned), and god knows what other bits you've got in this board. You're also assuming the fan is still perfectly mounted (which it might not have been in the first place), and that sort of thing.
TDP assumes, wrongly, that your card is perfectly clean, and that the fan controls are always correct, which might be the case on a reference designed card, but might not quite be the case on factory overclocked boards or if there have been aftermarket tweaks to the driver to adjust the fan speed (which is usually a noise problem). A few other new games have had this issue (notably Star trek online).