3
$\begingroup$

I'm wondering what happens with the framebuffer between the time that the fragment shader is done, and the time when it appears on my screen.

Is my understanding correct if I assume that the framebuffer is in memory on the GPU, which is then copied back to the CPU side after glDrawX is completed, and then fit to a window somewhere on the screen, and then sent through my HDMI cable (via the GPU again!) to my monitor?

$\endgroup$
4
$\begingroup$

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.

| improve this answer | |
$\endgroup$
  • $\begingroup$ I noticed while learning basic Direct3D recently, you generally specify a single framebuffer when creating your swapchain. I'm guessing this simply gets blitted to the compositor when 'swapping' buffers? How about when switching to fullscreen mode, does a separate front buffer get created for you in that case? $\endgroup$ – russ Nov 14 '17 at 4:05
  • $\begingroup$ I don't know the specifics about Direct3D, but both those guesses are plausible. Typically the application framebuffer looks like a texture to the compositor, which it'll put on a quad of the appropriate size and position. I have no idea what fullscreen on MS Windows does: it may be something more complicated. $\endgroup$ – Dan Hulme Nov 14 '17 at 10:47
  • $\begingroup$ If you ask a new question specifically about D3D fullscreen, it's more likely to be seen by someone who knows. $\endgroup$ – Dan Hulme Nov 14 '17 at 10:48
  • $\begingroup$ OK, was just curious about how this worked in general, didn't want to open a duplicate-ish question. I don't think it's API-specific anyway, since OpenGL under Windows uses the same DXGI backend as D3D does. $\endgroup$ – russ Nov 14 '17 at 12:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.