What is a frame buffer?

[chickenwings]

With this whole Xbox One resolution nonsense going on at the moment, I'm trying to get my layman head around what the fudge is going on, and what a frame buffer is. I believe it to be the final image that will be displayed to the screen.

Specifically what is being talked about in this tweet, relating to Ryse.

https://twitter.com/RealtimeCevat/statuses/384355681194614784

He talks about the game running at 1600*900 and then mentions upscaling for AA, and that the frame buffer is native 1080p.

I ran a few searches to see what the frame buffer is, but everything was at a too deeper level for me to understand!

To me, what he is saying almost suggests that the game is rendered at 1600*900, then upscaled to 1920*1080 and will be stored in the frame buffer at 1080p.

But when I read some comments and forums people seem to be talking as if the game is native 1080p, then it is rendered at 900p only to then be upscaled back to 1080p for AA. Which to me doesn't seem logical.

So is a 'native 1080p' frame buffer just brain washing and really it is just an upscaled 900p image being held in the buffer rather than outputing at 900p and say letting your TV upscale to 1080p to fill the screen?

I apologise if this is just a nonsense post!

 

[AlNom]

What they mean is that they upscale to the front buffer that the display hardware outputs (or first combines with the other display planes). The display then sees a "native" resolution signal so the 1080p display panel itself does not upscale.

really it is just an upscaled 900p image being held in the buffer rather than outputing at 900p and say letting your TV upscale to 1080p to fill the screen?

Yes.

 

[Shifty Geezer]

A frame buffer is literally a buffer to store a frame of image ready to display on the TV. Before framebuffers, graphics were drawn directly to the display output, and every drawing operation was visible as it happened.

Typically you have two framebuffers. One holds the current data being displayed, and the other is where you draw your new frame. When the drawing is finished, you swap the newly drawn framebuffer to the front and work on the other one. These are called the front buffer (one visible) and back buffer (one being drawn on) respectively.

For display purposes, you need to stretch the image to fit the screen. If the console is to do this, it needs to take a framebuffer at a resolution and upscale it to the output resolution. In the case of Ryse, it'll be rendering 900p into the back buffer and upscaling to 1080p when swapping to front buffer (or, alternatively, rendering into 900p into another buffer, upscaling that to 1080p, adding more stuff like UI, and finally swapping to front).

 

[Project Alice]

I have a follow up question to the OP's inquiry. How fast does the frame buffer have to write? How many GB/s does the memory have to be to output 1080p at 60fps?

 

[taisui]

you can start with 1920 x 1080 x 60 x 32bit, but it's really a more complicated question.

 

[Davros]

At 1920 x 1080 a single frame is 6mb so 360mb/s for 60fps

 

[Project Alice]

Davros, forgive me in advance as I'm just a layman, I think I'm asking it wrong. The DDR3 of the XBOX One is rated at 68 GB/s. I keep reading that that is too slow for a frame buffer.

Then I also remember the XBOX One Technical fellow saying you could split the frame buffer between the DDR3 and the eSRAM. Anyone know how that would work? Could you have a front buffer go through the DDR3 with the back buffer through eSRAM?

I'm lost on this. Thanks.

 

[taisui]

it's not just the frame buffer, everything needs bandwidth (mesh, texture, data, etc), with the majority of it being multiple read/write to the frame buffer (whenever you blend a pixel, it's at least a read and a write), so the 360mb/s quickly grows to a huge number. Ideally, you would keep the high bw buffer (say, geometry buffer) in the eSRAM, and on the last pass you write it back to the DRAM. The 68GB/s along is not enough for typical rendering.

 

[Dominik D]

Too slow, why? FB is ~8MB, that's not even 1GB/s for 100FPS. But what embedded memory is great for is temp storage. You can render shadows to it and access them in a timely fashion. G-buffer could go there, a lot of things that would benefit from rapid access would benefit. Developers look at their access patterns and decide what goes where.

You can *probably* have any type of data anywhere (i.e. DDR3/eSRAM) - it's a matter of mapping it properly in the MMU.

 

[Shifty Geezer]

Davros, forgive me in advance as I'm just a layman, I think I'm asking it wrong. The DDR3 of the XBOX One is rated at 68 GB/s. I keep reading that that is too slow for a frame buffer.

Taisui explains the details. In constructing a framebuffer image, you need lots of bandwidth between assets and processors. To output the frames to screen, you only need as much BW as Davros's calculations - 360 MB/s.

 

[nightshade]

The easiest way to explain this would be to look at how movies work, you have multiple frames with still images moving at 24 frames per second which gives the appearance of a moving image or a video. Games do the same thing, except they only have two frames to use (three in case of a triple buffered game). So imagine a painter painting an image that gets displayed at the front and while it's displayed he's already working on the next image at the back on a second frame, once the second image is finished the frames are swapped and he erases everything on the first frame to draw the next frame. Now imagine repeating this whole process 30 times in a second, that's what games do.

 

[Davros]

I keep reading that that is too slow for a frame buffer.

Probably they are comparing it to the ps4 with it's 176gb/s bandwidth or p.c graphics cards that can have over 300gb/s

 

[ERP]

Davros, forgive me in advance as I'm just a layman, I think I'm asking it wrong. The DDR3 of the XBOX One is rated at 68 GB/s. I keep reading that that is too slow for a frame buffer.

Then I also remember the XBOX One Technical fellow saying you could split the frame buffer between the DDR3 and the eSRAM. Anyone know how that would work? Could you have a front buffer go through the DDR3 with the back buffer through eSRAM?

I'm lost on this. Thanks.

The front buffer requires very little bandwidth and generally you would use the eSRAM for the back buffer, then copy the result to the main memory for display, though as I understand it there is no requirement to do this on XB1.

In a real game however the reality is far more complicated, there are many off screen buffers that are used to produce the next rendered image, often several 100 MB's worth, which is where the 32MB ESRAM becomes a potential issue, using it optimally involves ordering rendering to allow you to render into the ESRAM then potentially copy that data out to main RAM, potentially asynchronously. At this point this data juggling can get complicated.

Worse the current popular rendering methodology is deferred rendering, the issue there is that one of those off screen the GBuffer can be very large, so large that it wouldn't fit into ESRAM at 1080P without careful selection of the data and the formats.