I don't mean to say that a single frame can take 100ms to render & that you can somehow add more pipeline stages. That's silly because the slowest single stage of your pipeline is the bottleneck.

I was instead saying that if you could re-architecture the entire system end-to-end so that you could generate 1/10th of the frame in 1/10th the time, & there wasn't a resource contention between frame (i.e. you would start processing the next frame as soon as you're finished with the current one), then even though it took 100ms for the entire frame to scan out, each individual section is still updating at 100 fps. Similarly, if you could get update the display in pieces rather than the one-shot serial operation as it is now, then you'd see some serious changes to our understanding of latency & pipelining.

This is all easier said than done & was a total strawman taken to an absolute extreme. However, if the SW could get that pipelined, HW vendors would have a much easier time making their end of it more efficient.

It's an interesting idea, but how would updating individual tiles at different rates appear to the user? Obviously if some parts of the frame remain static you could delay updating those, but how would it look in cases where the entire frame has changed such as during a camera pan? And how would it work with post effects like motion blur or DOF? Maybe it would look good at very high frame rates, but would the individual tiles updates become visible if your app encounters slowdown and FPS drops below 30? It's an interesting idea, and thanks for providing more info. However, I'd need to see a proof of concept, including post effects, before I considered it further.