1080P should be less than half a gig/s at 60Hz (I don't think it refreshes at 120)... And, I don't think front buffer would be in floating-point format either.
So... Where does 1GB/s come from?
N5 expected to use cutting edge processor and graphics tech
- Thread starter Megadrive1988
- Start date
1080P should be less than half a gig/s at 60Hz (I don't think it refreshes at 120)... And, I don't think front buffer would be in floating-point format either.
So... Where does 1GB/s come from?
Megadrive1988
Veteran
720p and 1080i are fine, resolution wise for next gen console games. what we'll need on top of that is a good FSAA method and plenty of it.
Guden Oden said:
1080P should be less than half a gig/s at 60Hz (I don't think it refreshes at 120)... And, I don't think front buffer would be in floating-point format either.
So... Where does 1GB/s come from?
1920x1080*4 bytes = 8294400 bytes
@ 60fps = 497664000 bytes. Round to 0.5 GB/s
You have to resolve from eDRAM to main memory so you use 0.5GB/s of eDRAM bandwidth and 0.5GB/s of main memory (for the write). The scanning out consumes 0.5Gb/s of memory bandwidth also. For a total of 1.5GB/s but only 1.0GB/s of main memory bandwidth.
DeanoC said:
Why? PS2 uses only on-chip bandwidth. Heck, is it even possible to copy framebuffer contents off the GS?
It would entirely depend on how the hardware's designed, but even assume front buffer in main RAM, I don't see how sacrificing around 1/20th of main memory b/w (assuming leaked nextbox document is true) would in any way be crippling. As the main memory will mostly be a texture/program data store and CPUs having cache hitrates of 90+ percent, there should be bandwidth to spare for video scanout. If direct pixel ops take place in eDRAM, that does free up a whole lot of bandwidth from main mem...
I was actually thinking about rendering bandwith when I posted that, but the copying and scanning of buffers is sizeable enough to register also, as Deano pointed out.Guden said:
Actually that could easily be 1GB/s for the eDram read if your backbuffers are 64bit.DeanoC said:
Do you really think front buffers will default to 32bit though? (I suppose you'd do 10bit/channel RGB there or a high precision YUV).
Because storing frontbuffer in eDRAM is a waste of lots of valuable eDRAM. for 1920x1080 its another 8 Meg.Guden Oden said:Why? PS2 uses only on-chip bandwidth. Heck, is it even possible to copy framebuffer contents off the GS?
Guden Oden said:
90%+ cache hitrates! I guess you will be rendering lots of spheres with low resolution textures then
That bandwidth calculation is just the cost of viewing it, now add in the eDRAM bandwidth consumed every time you render (think full screen quads, and particles!) and its hard to justify.
Its a simple cost/benefit calculation, 1080p would be so much slower there would have to be a REAL benefit to most customers to use it. And theres not, no extra horizontal and a reduction in flicker for a few people who top end TVs.
Fafalada said:Actually that could easily be 1GB/s for the eDram read if your backbuffers are 64bit.
Do you really think front buffers will default to 32bit though? (I suppose you'd do 10bit/channel RGB there or a high precision YUV).
I used 32bit backbuffers so I couldn't be accused of inflating figures. Just the 16Mb memory size scares me for a 64bit 1920x1080 buffer.
I don't think we will get any options to have frontbuffers anything else than 32bit. 10bit/channel frontbuffers will match (beat) TV colour resolution pretty well, and having anything else would require more expensive DACs.
Similar threads
