Next-gen tech? Rambus targets 1TB/s memory for 2010

Increasing one without the others only makes sense to a degree.
If the cost to increase one way beyond balancing point is negligable, it's worth doing though. If 1 TB/s is possible without a premium, I say go for it and save developers one headache. They can forget all about BW concerns and work with one less variable, concentrating on how to use available processing power and RAM without ever having to worry about conflicting RAM access (bar latency, which hopefully the processing hardware will deal with effectively).
 
If the cost to increase one way beyond balancing point is negligable, it's worth doing though.

Well, take the SPUs, for example. What would you do with more bandwidth? The way it is now, you can load one qword per clock (OK, minus a little for code fetch, but that has lower priority). Unless you change the SPE itself to be able to consume more data, no increase in bandwidth will give you a speed-up.

On the other hand you statement is absolutely true for memory size. You can always use more memory. :)

Now going 1TB/s is certainly a cool thing, and having a UMA system like that in the next gen would make me a very happy puppy. The only thing I would be worried about is latency, as you said. XDR isn't exactly low-latency right now and I would be surprised if there was a massive change in that.
Having high latency requires caches, caches get less effective with increasing cache-line size and 1TB/s sounds like huge burst transfers and thus huge L2 cache lines to me.

...then again, I could be totally wrong. ;)
 
Well my post was not a reply to yours, it's to Shifty's ;) It's just what kind of technology is available at the forefront of eDRAM chip technology for game consoles in 2009. Another important characteristic in NEC's UX8GD is its operating clock speed, it's up to 800Mhz. So this is your limit, if you want a chip in 40nm around 800Mhz, you are pretty much capped to 32MB eDRAM.

For 1080p+4xMSAA at 16bit HDR,

16bit HDR (64bit) + Z (32bit) = 12 bytes

1920 * 1080 * 12 * 4 = 99532800

it requires 94MB eDRAM.

32MB EDRAM just might be enough:

It will nicely fit
1280x720p 4xMSAA (32bit RT+Z)
or
1920x1080p 2xMSAA
which I find way more realistic for next gen.

Add to this some (more) programmable ROPS and you can get your HDR in 32bit per pixel (LogLUV) with no problem.
 
well its 40nm with 32mb of edram. What about 32nm which could be very likely in 2011 ? Has there been any news on 32nm tech or perhaps them pushing more edram on 40nm ?
 
What about two pools of ram?
1 or 2 GB of super fast ram, and 4 or 8 GB of cheap vanilla dram. So a shitload of high res data and high quality sound can wait in the slow pool and can be streamed into the fast pool pretty quickly or can directly be consumed.

Something like AMD's G3MX could be used to address the big slow pool, to save pins on the memory controller/chipset?
 
I hope next gen is 4x AA and 16x AF everywhere.
Hell if one vendor goes edram, I hope they target 720p, high IQ and 60fps (why not even support 120Hz output)
 
I hope next gen is 4x AA and 16x AF everywhere.
Hell if one vendor goes edram, I hope they target 720p, high IQ and 60fps (why not even support 120Hz output)

It may be fanciful wishing, but I'd hope for 1920x1080/60p being standard. But realistically, I'd settle for 1280x720/60p with 4xAA or 1920x1080/30p with 2xAA.

Neither will ever really happen, as there will always be devs who want to push stuff and we'll end up with 1440x1080 or 1280x700. But hopefully we'll see the end of super-sub HD (1024x600 CoD series or 680p PS3 Bioshock).

And another pipedream is devs stopping the use of a blur filter and trying to pass it off as a good thing.
 
Last edited by a moderator:
If the cost to increase one way beyond balancing point is negligable, it's worth doing though. If 1 TB/s is possible without a premium, I say go for it and save developers one headache. They can forget all about BW concerns and work with one less variable, concentrating on how to use available processing power and RAM without ever having to worry about conflicting RAM access (bar latency, which hopefully the processing hardware will deal with effectively).

Particularly I have always thought an extremely shader heavy design would work well in consoles, such as ATI's recent ones, seemingly.

In PC's of course if you unbalance with too many shader as AMD has done in the past at times, it doesnt pay off because the pre-existing software can be rigid and texture limited. But in consoles you mold the software to the hardware.
 
I really wonder if console manufacturers should persue such a goal as achieve 1TB/s worse of bandwidth for their next sytems. In fact I wonder if they should persue goals as "such resolution + such amount of AA".
As we speak of balanced systems, I think that RAM size should be favored to bandwidth. By reading devs comments on this board it often looks like the ratio computational/RAM size is broken on most console (I may missunderstand). We all know that edram is a saviour here but it cost grows along your framebuffer size and the amount of AA you want to apply.
In order to make free from this constrain Ms introduce some sort of tiling. After some years of developpements and by listening to some devs comments (some late Fran comments from example) it looks like the solution MS chose is far from optimal. From my understanding it's not that unpractical but it impose quiet some limitations in the way they would like to do thing on a system not tied to some API and the burden of compliance between multiple manufacturers.
More interestingly it looks like some devs found a work around by using selective form of AA (Epic for example, but Fran showed lot of interest in these technics too).
To me this looks like the future for consoles as it make the most of really few EDRAM and allow transistors to be invested elsewhere. Console manufacturers should really focus on making high level of AA achievable by using these technics.
Acutally I would know more about these technics work.
 
What about two pools of ram?
1 or 2 GB of super fast ram, and 4 or 8 GB of cheap vanilla dram.
That's a bit the elephant in the room, isn't it? People are talking (and prefering) UMA architectures a lot, but deepening the memory hierarchy is a definite option.

I would guess that if your slow mem is fast enough to replace 25% of your fast mem per 16ms frame, there is not much left to ask for. For 2GB, that means 30GB/s, if my math checks out.

I'd take it. ;)
 
That's not unfeasible, but would it actually be cheaper? The GDDR in the PS3 and XB360 is now more expensive than the standard stuff. An extra 1GB pool of last-gen DDR in the PS360 would be adding a lot of cost, possibly more than going with a round 1GB of GDDR. Adding slow ram would need to come from a pool that'll be cost effective for the entire generation, and given the way RAM moves on, that seems unlikely. Is there a 30 GB/s RAM type that'll be cheap for the next gen and still be cheap 10 years later?
 
@ Shifty, are you saying the GDDR3 in the PS3/Xbox 360 is more expensive than the DDR2 of today? If thats what it is, is the difference significant or minor?
 
AFAIK it is, based on discussions here that's considered replacing GDDR with DDR in slim remodels of the consoles. If no-one else is using GDDR3, it becomes a proprietary format that needs specialist producers instead of a nice large, competing market driving prices down. I don't know at all what industry prices are though. All I know is 1 GB of RAM for my AthlonXP 2500 PC (266 MHz) costs £35 for which I could get 4 GBs of contemporary RAM (800 MHz). And 512MBs of SDRAM, mainstream tech 8 years ago, now costs £50! If PS2 was fitted with SDRAM, it'd cost a lot to buy that in. I don't know who makes the RDRAM in PS2.
 
That's not unfeasible, but would it actually be cheaper? The GDDR in the PS3 and XB360 is now more expensive than the standard stuff. Is there a 30 GB/s RAM type that'll be cheap for the next gen and still be cheap 10 years later?

Good point. Price development is always pretty.... flexible. I would suspect that for something like "slow" RAM, you could simply take what's currently cheap as long as it a) is faster than a certain minimum (which is in your devkits) and b) you have a memory interface for it. The latter could be helped by something like FlexIO, which seems to have been designed for having different memory systems attached to it.

This brings up the slightly off-topic topic of how fixed you want your hardware to be. As long as you don't just map that slow mem into the same virtual address space as regular mem, you can probably add a thick enough layer to deal with slight differences in hardware.
 
Back
Top