Aaaaaaaa! We need subsample accuracy. Whether it comes as plain vanilla MSAA or some new BBQAA, IQ is going to want more samples than pixel next gen. Post AA isn't enough on its own.
Predict: The Next Generation Console Tech
- Thread starter Acert93
- Start date
- Status
Isn't a FP16 render target 8 bytes per pixel ? That would yield 48MB for three FP16 1920x1080 render targets. 4 x MSAA requires 16 bytes per pixel (assuming 32bit depth), so we end up with 80MBs for 3x FP16+4xMSAA 1920x1080.
Regarding size, IBM's 1mbit eDRAM macro is 0.24 mm² in 45nm. David Kanter has speculated that density in 32nm is over 11Mbit/mm², or 47mm² for 64MB eDRAM.
I wouldn't rule out 128MB. With virtual texturing we could see GPUs executing almost exclusively out of eDRAM (considering Sebbi's working set size estimates in an older thread). While the extra eDRAM would add cost, it would also imply a savings on the rest of the memory system
Cheers
french toast
Veteran
Yea i was thinking this for ages, and always wandered about having a much larger sizr edram..but over at the other thread they seemed to think that edram was too expensive...
In you edram scenario, how would that be implemented? on die with the gpu? or daughter die ala xenos..
In you edram scenario, how would that be implemented? on die with the gpu? or daughter die ala xenos..
Isn't a FP16 render target 8 bytes per pixel ? That would yield 48MB for three FP16 1920x1080 render targets. 4 x MSAA requires 16 bytes per pixel (assuming 32bit depth), so we end up with 80MBs for 3x FP16+4xMSAA 1920x1080.
You need to AA the render targets...
AA * resolution * (N rendertargets * byte per pixel + 4 bytes per pixel depth)
So your three 4xMSAA FP16 1080p render targets are going to be 189.84MB, not 47.46.
The question wasn't specific to a particular res or AA, just that he wanted something close to 128MB, and a deferred MSAA setup with either a 32bpp or 64bpp format for the MRTs would get there.
AlStrong I know that can be painful to always return to this argument 
but there's a future rendering tech that isn't mainstream now and that will work fine with "only" 128MB of edram?
so that for the moment you use traditional rendering waste the potential of the edram, but in 2 years when start to appear some custom engine you can do the mid generation graphic jump
but there's a future rendering tech that isn't mainstream now and that will work fine with "only" 128MB of edram?
so that for the moment you use traditional rendering waste the potential of the edram, but in 2 years when start to appear some custom engine you can do the mid generation graphic jump
I think we're still pretty early into exploiting MRTs. GPUs have had the capability of doing eight since DX10/G80, and due to the extended generation and waiting for PC gaming baseline hardware to catch up in performance, it'll be awhile yet before that's really explored (what sorts of things devs can store within each buffer and how they use it).
Fat G-buffers are probably here to stay for awhile, but who knows how the caches are going to be setup in the GPU itself and what level of API exposure there will be to further exploit that.
128MB is quite a lot without MSAA enabled.
Fat G-buffers are probably here to stay for awhile, but who knows how the caches are going to be setup in the GPU itself and what level of API exposure there will be to further exploit that.
128MB is quite a lot without MSAA enabled.
(((interference)))
Veteran
It's great to see some solid rumours. So it's pretty much certain that they're going with PowerPC, eDRAM and a AMD GPU and not something like a bunch of ARM cores or x86.
Though I'm a bit worried by the talk of only 2GB RAM, is that really going to be enough? I'd have expected at least 4 GB, I mean smartphones are moving to 1 GB of RAM already.
Though I'm a bit worried by the talk of only 2GB RAM, is that really going to be enough? I'd have expected at least 4 GB, I mean smartphones are moving to 1 GB of RAM already.
And again (at least AFAIK and no-one told me wrong yet on this), there isn't big enough GDDR5 memory modules to allow anything over 2GB on 128bit bus, and even that means clamshelling already.
256bit bus sets new requirements of GPU size (you need to account die shrinks too), not to mention PCB complexity and size (memory modules do take some space, too)
I'm still liking the idea of a 192 bit bus as a compromise and with avoidance of EDRAM.
People talk about all the savings EDRAM can engender, but it itself is going to be very expensive and a performance robber, people dont take that into account.
192 may require a slightly bigger die down the road but if it saves you huge performance costs (transistors for EDRAM instead going to functional units) it may easily be worth it when they calculate the spreadsheet. It also enables 3GB RAM easy enough, which still isn't enough imo, so I'd say 6GB.
If you are looking at EDRAM I'd expect 128MB is crazy talk, 32/64 I would think max would be reasonable.
People talk about all the savings EDRAM can engender, but it itself is going to be very expensive and a performance robber, people dont take that into account.
192 may require a slightly bigger die down the road but if it saves you huge performance costs (transistors for EDRAM instead going to functional units) it may easily be worth it when they calculate the spreadsheet. It also enables 3GB RAM easy enough, which still isn't enough imo, so I'd say 6GB.
If you are looking at EDRAM I'd expect 128MB is crazy talk, 32/64 I would think max would be reasonable.
Yeah... even if scaling were ideal and if high performance 28nm eDRAM were even ready, the console company would need to have a bigger die budget than what MS had for the 360 in order to exceed 80MB.
Now, that ignores the functional units integrated into the daughter die design (ROPs, Z/stencil), but as you know those have changed a fair bit in the last few years (RBE configuration, Z/Stencil rates, texture formats, blending support etc). And who knows what it'll take to increase the usefulness of the edram...
Were did you get that from?
Devious
Regular
That's pretty much why I mentioned 128MB is out of the equation. I just wanted to see different scenarios in which developers would reach the maximum (or close to) of 128MB eDRAM.
And thank you AlStrong for providing that info at both 720 & 1080p with 2-4x MSAA. Really helpful! :smile:
The problem I have with this rumor is that the final Wii U chipset/ SoC supposedly went into production at almost exactly the same time and the system is expected to launch much earlier. Wires crossed, maybe?
EDIT: Oban is just a small town somewhere in Scotland. Ōban on the other hand was the largest gold coin in feudal Japan.
Last edited by a moderator:
It was Northern Islands when it got released, though
I know, If it started production in December 2011 and is a custom chip you can pretty much guarantee that Microsoft had this chip designed along side the desktop version and made at the same time.
Quesion is, What did they do to make it 'custom'
What could they of removed and stripped out that was not needed for a console GPU, Eyefinity logic? And what could they have added?
- Status
Similar threads
- Locked
