6
$\begingroup$

Question from the graphics newbie:
What I know by now is that "usually" double buffering is used:
You calculate the content of frame x+1 while frame x is shown on the screen, if you want to achieve the maximum update rate, calculation must not take longer than one frame time, otherwise the "drawing process" is visible.
So, having two framebuffers absolutely makes sense, and I guess that's why we have that "glfwSwapBuffers" call in some OpenGL tutorials.

But what if I program my things in a way that every primitive leads to fragments that are horizontal lines, and let the GPU process it from top to bottom line "on the fly"?
In this case I would need only one framebuffer that could be filled with a static background, and I would only have to store the other objects in some much smaller memory.
Is this possible at all?
Is there even any GPU implementation that does it that way to save memory?

Improve this question
$\endgroup$
1
  • 2
    $\begingroup$ Just as an aside, sometimes, if you have the memory to spare, triple buffering is used. This allows more flexibility in the rendering rate. Imagine you are targeting 60Hz but occasionally the renderer takes > 1/60th of a second. With double buffering, this would cause a dip to 30Hz. Triple buffering allows the update rate to remain more stable but at the price of more latency. $\endgroup$
    – Simon F
    Commented Oct 16, 2019 at 9:22

1 Answer 1

Reset to default
9
$\begingroup$

Indeed there are/were 'just in time' renderers.

For example, Dreamcast (PowerVR CLX2) had a mode where the 'frame buffer' only had to be a few rows of tiles in size. The system would be rendering into one row while the display was reading out of some subset of the others. It would then cycle through the buffers.

In order to do this, however, you do need a display-list rendering system. A standard 'immediate mode' renderer is not appropriate.

Of course, scene complexity needs to be considered carefully for this sort of scheme to work. In particular, if one tiny section of the screen contains particularly complex geometry, the renderer might not finish it in time before the display needs to read it. Allocating more memory for the partial screen buffer allows for more variability in scene complexity.

I also have a feeling/seem to recall some old (e.g 60s/70s?) flight simulators might have rendered 'on the fly' because memory (for a frame buffer) was once fiendishly expensive.

Alternatively, the PowerVR PCX1/PXC2 ports of Tomb Raider had an optional single buffered rendering mode. (This was primarily because one of the guys doing the port (cough, me, cough) only had a 2MB 2D graphics card which could only allocate a single 1024x768 framebuffer). Again, since the system was tile-based, it didn't suffer from the nasty artefacts you'd get with single buffering on a traditional Z-buffer system.

UPDATE: FWIW there's another related question on "Racing the Beam" here

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Another interesting reference: Frameless Rendering: Double Buffering Considered Harmful, Bishop et al, SIGGRAPH '94. $\endgroup$
    – Hari
    Commented Jan 4 at 11:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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