> legacy rendering performance is improved by single-digit percentage points, I believe.
I feel like one would expect this, given that the rendering engines of any given generation, are architected under specific assumptions about the optimal relative "shape" of their graphics pipeline.
The clearest example being old game consoles. You could write a SNES emulator for the SuperFX coprocessor, that used the host's GPU to render the polygons, but the rendering would not go any faster than it does on the SNES, because the draw commands are just being trickled out as the physics-engine work necessary to update their positions gets done in fits and starts per scan-line. That trickling-out was necessary on a SNES, because there wasn't time to run all that logic during VBLANK; but in the modern era, we have the opposite problem — that the logic could all be completed during VBLANK (with tons of room to spare), but instead is being "dragged out" across 512 HBLANKs, such that the GPU only gets the full picture of the completed scene at the last moment. (Despite the recent source-code leak, rewriting StarFox to make it render at 60FPS or more will not be a trivial process.)
The same thing is true, to a varying extent, of all legacy renderers. They're written for graphical pipelines that just don't match the one we have now. The one we have now is "wider" — more parallel — in so many places, but if it's just being used to recapitulate a long, serial set of fixed-function legacy pipeline stages, that width doesn't help it any.
I feel like one would expect this, given that the rendering engines of any given generation, are architected under specific assumptions about the optimal relative "shape" of their graphics pipeline.
The clearest example being old game consoles. You could write a SNES emulator for the SuperFX coprocessor, that used the host's GPU to render the polygons, but the rendering would not go any faster than it does on the SNES, because the draw commands are just being trickled out as the physics-engine work necessary to update their positions gets done in fits and starts per scan-line. That trickling-out was necessary on a SNES, because there wasn't time to run all that logic during VBLANK; but in the modern era, we have the opposite problem — that the logic could all be completed during VBLANK (with tons of room to spare), but instead is being "dragged out" across 512 HBLANKs, such that the GPU only gets the full picture of the completed scene at the last moment. (Despite the recent source-code leak, rewriting StarFox to make it render at 60FPS or more will not be a trivial process.)
The same thing is true, to a varying extent, of all legacy renderers. They're written for graphical pipelines that just don't match the one we have now. The one we have now is "wider" — more parallel — in so many places, but if it's just being used to recapitulate a long, serial set of fixed-function legacy pipeline stages, that width doesn't help it any.