Earlier quoted context omitted.
Both Nvidia (and AMD?) have options to reduce latency to like 1 frame (edit: due to render ahead queue; not total latency) in their control panels. You probably pay for it with a bit of stutter when your system is pushed to the max - since there is no leeway buffer when frames don’t get finished in time. Display latency from LCDs are another factor - something that was completely absence on CRTs.
That actually isn't particularly helpful. Picture the rendering process like a conveyor belt factory. This is a bit of a simplified model, GPUs are incredibly complex and things aren't quite this straightforward, but it's good enough way of reasoning about how they operate by imagining something like Factorio. First you load up a scene, and then it goes into one machine that does the first part of the rendering, then…
In game engines, long frame pipelines were all the rage in the early 2000's to distribute work across CPU cores without having to rewrite entire single-threaded systems to multithreading (so you might have a pipeline of input-, AI-, physics- and render-thread, each adding one frame of latency).
But that's also when "input latency" became a problem, so game engines went away from this pipeline architecture and ran all those steps in a single frame by parallelizing within systems, but still chaining the inputs and output of those big systems together in a linear sequence (but all ideally within one frame).
After that came the general task schedulers, where everything that needs to happen in one frame is split into very small tasks arranged in a dependency tree, and those small tasks are run by a general task scheduler running on a thread pool (sometimes even on the GPU).
The general goal is to distribute the same work across available CPU and GPU resources, but without introducing a deep frame pipeline, and for the only reason to reduce button-to-screen latency (while still cramming as much work as possible/needed onto the CPU and GPU).