Details on the new Toshiba fab in Oita

[megadrive0088]

The PS3 with a Visualizer (4 pixel pipelines, 1 per PE) would not match or even come close to the fillrate of GSCube (either GSCube).

first GSCube had 16 GSs * 16 pipes @150 Mhz = 38,400M pixels/sec untextured fillrate (each GS has 16 pixel pipes)

2nd GSCube had 64 GSs - * 16 pipes @ 150 Mhz 153,600M pixels/sec
untextured fillrate

(half that for textured, bilinear filtered if I calculated right, and the actualy official fillrate figures are a bit lower due to clock speed being 147 Mhz)

plus 32MB eDRAM per GS
(512 MB eDRAM for the 16 GS GSCube, 2048 MB eDRAM for 64 GS ver!)



edit: not that it MATTERS to have that MUCH fillrate, as Panajev pointed out in the post just before this one. just wanted to give an idea of the massive, massive fillrate the GSCubes have.

 

[overclocked]

What will a HDTV cost when PS3 comes out i wonder, it would be like a joke having such a powerful beast output at 640*480.

 

[Panajev2001a]

64 MB = 512 Mbits

64 MB would take probably 550-600 MTransistors, but the die-area used is not immensely big.

Embedded DRAM cell:
High-speed data processing requires a single-chip solution integrating a microprocessor and embedded large volume memory. Toshiba is the only semiconductor vendor able to offer commercial trench-capacitor DRAM technology for 90nm-generation DRAM-embedded System LSI. Toshiba and Sony have utilized 65nm process to technology to fabricate an embedded DRAM with a cell size of 0.11um2, the world's smallest, which will allow DRAM with a capacity of more than 256Mbit to be integrated on a single chip.

http://www.toshiba.co.jp/about/press/2002_12/pr0301.htm

We might see 32 MB on the Broadband Engine and 32 MB on the Visualizer and 256 MB of Yellowstone DRAM ( 25.6 GB/s ) as external memorywhich would not be that bad IMHO

I'd rather have 64 MB of e-DRAM, but I want to see the console shipping...

They say "more than 256 Mbits"... maybe the Broadband Engine will have 64 MB and the Visualizer will have 32 MB...

It is also true that Sony and Toshiba are hard at work on their 45 nm manufacturing process and that they want to switch to it as soon as possible.

If the transition to 45 nm is not going to be REALLY long they might indeed take the losses and put 64 MB of e-DRAM on the Broadband Engine at least ( the Visualizer has Image Caches and 32 MB of e-DRAM would not be too bad even for HDTV resolutions ) as with the transition to a 45 nm manufacturing process they could shrink the processors quite nicely and reduce manufacturing costs significantly.

 

[Paul]

What will a HDTV cost when PS3 comes out i wonder, it would be like a joke having such a powerful beast output at 640*480.

HDTV will be standard in 2005, your not going to see stores selling analog TV's. The price will be just like an average TV set now.

 

[megadrive0088]

yeah I would like 64 MB on Broadband Engine and 64 MB on Visualizer
plus 512MB - 1 GB main memory. system memory is so cheap these days, developers would be grateful to get alot of memory this time. it also works well if Sony wants to have the most powerful machine in the next gen. I think that would happen only if PS3 doesn't ship until 2006. otherwise I expect 64MB eDRAM CPU, 32 MB eDRAM GPU, 256-512 MB main mem for a PS3 that ships in 2005.

 

[overclocked]

That sounds fine, a PS3 and a HDTV it is then in 2005.

So 500~m/transistors(both chipsets?) would be equal to the "original" PS2 chipsets in cost etc, btw do you count the eDRAM in that?

 

[Vince]

yeah I would like 64 MB on Broadband Engine and 64 MB on Visualizer plus 512MB - 1 GB main memory.

Whoa... I just want 32MB of eDRAM and 256MB of whatever Rambus can muster. This isn't Jesus incarnate, just a console chip. Besides, this architecture will be fundimentally diffrent than anything you've yet seen on the PC scene... don't judge it by those standards.

After-all the Visualizer has dedicated silicon for 3D rendering ( Pixel Engines, Image Caches and CRTCs ) and that part might be the evolution of this compact and streamlined version of the super-GS... evolved inside a Cell chip...

"Super GS" ?!? You sound like Ben, it's scaring me. This isn't a damn, dirty PC. Sony isn't nVidia or ATI. They don't need fragment shading, it's redundent to anything but the short-term PC IHV's agenda. Lets think more elequent like Renderman en silico, than a GS wantabe R300.

Besides, designing any forwardlooking IC with hardwired/semi-wired features is idiotic. Put everything you can programmable except those things which are massively parallel or recurrent (eg. Filtering).

 

[Panajev2001a]

The GScube also did not have a very flexible Rasterizer ( needing to waste more rendering passes ) and was going to render at quite insane resolutions and with good AA on so its fill-rate need was enormous.

4 GPixels/s and 4 GTexels/s ( which is better than a GS like chip with 4 GPixels and 2 GTexels ) with ~128 GFLOPS and ~128 GOPS ( 1 GHz clock ), consideing we have dedicated silicon for things like texture filtering, and that T&L is done by the TFLOPS class Broadband Engine is not that bad

1280x720p = 921,600 pixels

That means we could render the whole screen ~4,340x in a second.

1280x720p * 60 fps = 55,296,000 pixels to be rendered each second.

( 4 GPixels/s ) / ( 55,296,000 ) = ~72

 

[jvd]

planed mass production is second half 2004

Start of mass production in the latter half of first half of FY2004 (planned)

my bad missread , finals and all , not much sleep . So then no problems most likely spring of 2004 for mass production

 

[vers]

32 MB for Visualizer is LITTLE

1200*720 pixels 32 bit color+32 bit Z about 6 MB

for 4 PE= 4*6=24MB

and double buffer for CRT 6MB

=30MB

32-30= 2MB texture cache???? DD

64MB is possible 30MB for buffer and 32 MB for texture cache

 

[Panajev2001a]

yeah I would like 64 MB on Broadband Engine and 64 MB on Visualizer plus 512MB - 1 GB main memory.

Whoa... I just want 32MB of eDRAM and 256MB of whatever Rambus can muster. This isn't Jesus incarnate, just a console chip. Besides, this architecture will be fundimentally diffrent than anything you've yet seen on the PC scene... don't judge it by those standards.

Vince I do see 32 MB on each the Broadband Engine and the Visualizer GPU, but I also allowed myself to think about 45 nm coming "not too long" after PlayStation 3 debut and that 45 nm would reduce manufacturing costs and bring 64 MB of e-DRAM in the realm we call reality

32 MB of e-DRAm on Broadband Engine and 32 MB of e-DRAM in the Visualizer plus 256 MB of Yellowstone DRAM as external RAM is IMHO more than acceptable accounting texture and geometry compression ( 2D and 3D TC and HOS for geometry compression ).

The bandwidth for the Yellowstone DRAM should be 25.6 GB/s and on the two Cell chips the e-DRAM sits on a fat 1,024 bits pipe (1-2 GHz could be its clock speed... in that case we would have 128-256 GB/s... even at 500 MHz this would still be 64 GB/s which is not too horrible, but I would expect more than that... what do you think Vince ? ).

After-all the Visualizer has dedicated silicon for 3D rendering ( Pixel Engines, Image Caches and CRTCs ) and that part might be the evolution of this compact and streamlined version of the super-GS... evolved inside a Cell chip...

"Super GS" ?!? You sound like Ben, it's scaring me. This isn't a damn, dirty PC. Sony isn't nVidia or ATI. They don't need fragment shading, it's redundent to anything but the short-term PC IHV's agenda. Lets think more elequent like Renderman en silico, than a GS wantabe R300.

Besides, designing any forwardlooking IC with hardwired/semi-wired features is idiotic. Put everything you can programmable except those things which are massively parallel or recurrent (eg. Filtering).

Vince... when I said dedicated silicon for 3D rendering I meant filtering and maybe texture decompression ( which could be handled by the APUs... ).

You know I would like as you would to have PlayStation 3 with a micro-polygon like approach and I do advocate for a very fast and streamlined ratserizer.

I am sorry I confused and scared you: but I do not see a mainly hardwired GPU as something at all streamlined.

When I was mentioning a super-GS I was thinking about a chip that might go along the Broadband Engine if we were not using a Cell based Visualizer, which I do think we should see...

Super-GS in my mind was a chip that it is mainly designed to push a lot of pixels and draws lots of small polygons at ultra speeds and not focusing on heavvy HW based multi-texturing and tons of HW features... I said I wanted programmability and the APUs in the Visualizer would give it to me too...

 

[Panajev2001a]

32 MB for Visualizer is LITTLE

1200*720 pixels 32 bit color+32 bit Z about 6 MB

for 4 PE= 4*6=24MB

and double buffer for CRT 6MB

=30MB

32-30= 2MB texture cache???? DD

64MB is possible 30MB for buffer and 32 MB for texture cache

Why do you multiply 6 MB by 4 ?

1280 * 720 * 4 bytes/pixel * 3 ( front-buffer, back-buffer and Z-buffer ) = 10.54 MB

 

[vers]

32 MB for Visualizer is LITTLE

1200*720 pixels 32 bit color+32 bit Z about 6 MB

for 4 PE= 4*6=24MB

and double buffer for CRT 6MB

=30MB

32-30= 2MB texture cache???? DD

64MB is possible 30MB for buffer and 32 MB for texture cache

Why do you multiply 6 MB by 4 ?

1280 * 720 * 4 bytes/pixel * 3 ( front-buffer, back-buffer and Z-buffer ) = 10.54 MB

all visualizers have own buffer , this is 4 buffer(color+z)

 

[Panajev2001a]

Why would you want 4x AA at 1280x720p ?

Talk about over-kill

I do not see why each Pixel Pipeline ( each Processor Element ) of the Visualizer should need a full resolution buffer...

We do not have 16 or 8 full resolution buffers on the PlayStation 2's GS...

 

[vers]

Why would you want 4x AA at 1280x720p ?

Talk about over-kill

I do not see why each Pixel Pipeline ( each Processor Element ) of the Visualizer should need a full resolution buffer...

We do not have 16 or 8 full resolution buffers on the PlayStation 2's GS...

ps2' GS draw only 1 polygon ,but 16 pixel/cycle
4 visualizers draw 4 poly/cycle

 

[Panajev2001a]

You have heard of screen tiling right ?

 

[vers]

You have heard of screen tiling right ?

tiling SLOW

 

[Kolgar]

Oh, sheeit. Microsoft and Nintendo are SO screwed!

Kolgar

 

[Panajev2001a]

Tiling slow ? well leaving 2 MB of texture buffer and filling VRAM of so much redundant data would get you the same treatment by SCEI upper management as a guy in IA-32 compiler team would have gotten if he said "but optimizing the Intel C/C++ compiler takes too much effort" and he would have rather had 512 KB L2 and super RISC style FPU from the beginning...

Nobody ever heard of that guy again ( I do not think anyone said that )

I do not think it would be safe for Sony's engineer put in the feature list 64 MB of e-DRAM and justify the extra 32 MB because of not wanting to use tiling to save memory and thus ending up with more than 32 MB of data ( you didn't calculate the back-buffer... we have 4 back-buffers, 4 front-buffers and 4 Z-buffers in your example... we could spill out of 32 MB without even 1 texture in the e-DRAM )



Seriously, I think that tiling the screen in 4 big chunks would not be THAT impossible and traumatic problem... I would rather do it myself in software if I had to as I'd rather deal with that than having 30 MB of frame-buffer + Z-buffer ( without even counting AA ) and only 2 MB of e-DRAM left for textures...

 

[Vince]

Are we sure we want AA as a raster based solution? I really don't know yet and have forgotten much of my knowledge from the 3dfx days and don't have the time now to research it. Also, whose to say you're going to use massive texturing if you're drawing a massive amount of micropolygons and utilizing HOS for everything.

This is why I question much of what's being stated here; many are applying the current PC paradigm to PS3.