It entirely depends what hardware and OS you're on. It's up to the integration between the windowing system and GL. In the simple case where one application is rendering full-screen directly, the framebuffer is in memory that's accessible by both the GPU and the display controller. After the GPU is finished, and when the display controller gets to a vsync (the time to start drawing a new frame to the screen), the display controller just reads out the framebuffer.
In a compositing system like modern MS Windows or Android, your app's framebuffer is not used by the display controller directly. After you finish drawing your frame, the compositor runs. On the GPU, it reads in your framebuffer, puts it in the right place on the desktop, and writes the composited desktop into the real framebuffer. The display controller then reads out the desktop framebuffer. There's also an optimization possible using overlays, which we have another question about.
Copying completed frames into CPU memory is to be avoided. If you had to do this every frame, your application probably couldn't run at a reasonable frame-rate. Even reading back a single pixel (with glReadPixels
) is a big slow-down, because the CPU has to wait for the GPU to finish, and they have to invalidate the cache of any shared memory. Reading back a million pixels is extra slow on desktop because the CPU and GPU have separate memory and the path between them is relatively slow. It's very rare that it should be necessary: mainly it's needed for screenshots, or for debugging.