PS3 Visualizer
- Thread starter vers
- Start date
sentences usually have a subject, a verb and an object.... then u can play around with it to create things called "statements"... u know, so people can actually understand what u're saying....
anyway, to stay on topic, we dont know fuck all about the PS3 visualiser, so why bother....
aint u the one who posted that thing about bump mapping on PS2? or was it someone else?
anyway, to stay on topic, we dont know fuck all about the PS3 visualiser, so why bother....
aint u the one who posted that thing about bump mapping on PS2? or was it someone else?
Panajev2001a
Veteran
Yes... the Visualizer has 4 pipelines...
A 4x1 configuration is possible...
You clock that puppy at 1 GHz and that means 4 GPixels/s and 4 GTexels/s
Not bad considering the FP and Integer power the 16 APUs present should bring to the table
He is referring to the Visualizer chip shown in the Cell patent
A 4x1 configuration is possible...
You clock that puppy at 1 GHz and that means 4 GPixels/s and 4 GTexels/s
Not bad considering the FP and Integer power the 16 APUs present should bring to the table
He is referring to the Visualizer chip shown in the Cell patent
Panajev2001a said:Yes... the Visualizer has 4 pipelines...
A 4x1 configuration is possible...
You clock that puppy at 1 GHz and that means 4 GPixels/s and 4 GTexels/s
Not bad considering the FP and Integer power the 16 APUs present should bring to the table
He is referring to the Visualizer chip shown in the Cell patent
You've got to get it clocked at 1ghz first. Thats not an easy thing to do even at .65nm (if thats what they are using for the graphics chip)
Panajev2001a
Veteran
The GS could clock at 150 MHz using 2,560 bits e-DRAM and using 250 nm technology and no SOI, we are talking about 1,024 bits this time and using 65 nm technology with SOI...
Also the e-DRAM can be clocked a bit lower than the rest of the chip... if they really need it...
Also the e-DRAM can be clocked a bit lower than the rest of the chip... if they really need it...
megadrive0088
Regular
It just seems odd to me that Visualizer (or GS3) would have only 4 pipelines. perhaps the patent was simply an illistration/example of how CELL could be transformed into a graphics processor.
Does that actually mean PS3's GPU will only have 4 pixel engines? even with the 1 GHz clock, it doesnt seem like much fillrate. I would tend think that Sony has not revealed the architechure of PS3's graphics processor yet.
I was thinking at least 16 pipes (as much as GS in PS2 has) at 1 to 1.5Ghz
with 1 texture unit each at least. if not, perhaps a new texture unit that can produce more than 1 texture/effect per cycle (like Flipper's TEV)
16 pixel engines * 1 or 1.5 Ghz gives us 16-24 gigapixels and at least
16-24 gigatexels if 1 texture unit per pipe and 1 texture per cycle.
but I know Panajev will disagree saying that 4 gigapixels/4 gigatexels is enough with the integer/FP units of the APUs and PUs of Visualizer.
Does that actually mean PS3's GPU will only have 4 pixel engines? even with the 1 GHz clock, it doesnt seem like much fillrate. I would tend think that Sony has not revealed the architechure of PS3's graphics processor yet.
I was thinking at least 16 pipes (as much as GS in PS2 has) at 1 to 1.5Ghz
with 1 texture unit each at least. if not, perhaps a new texture unit that can produce more than 1 texture/effect per cycle (like Flipper's TEV)
16 pixel engines * 1 or 1.5 Ghz gives us 16-24 gigapixels and at least
16-24 gigatexels if 1 texture unit per pipe and 1 texture per cycle.
but I know Panajev will disagree saying that 4 gigapixels/4 gigatexels is enough with the integer/FP units of the APUs and PUs of Visualizer.
Panajev2001a
Veteran
dp
Panajev2001a
Veteran
4 GPixels/s == 1.6x pixel fill-rate of the GS
4 GTexels/s == 3.2x texel fill-rate of the GS
1 GHz * 16 * 8 = 128 GFLOPS
1 GHz * 16 * 8 = 128 GOPS
4 GTexels/s = 1920x1080p * 60 fps * 32 ( over-draw )
This puppy can support an overdraw of 32x at 1080p...
Or an over-draw of 10x with 3.2 texture layers per pixel in average...
With micro-polygons each micro-polygon is likely to be single textured so the 32x maximum overdraw makes a bit more sense...
4 GTexels/s == 3.2x texel fill-rate of the GS
1 GHz * 16 * 8 = 128 GFLOPS
1 GHz * 16 * 8 = 128 GOPS
4 GTexels/s = 1920x1080p * 60 fps * 32 ( over-draw )
This puppy can support an overdraw of 32x at 1080p...
Or an over-draw of 10x with 3.2 texture layers per pixel in average...
With micro-polygons each micro-polygon is likely to be single textured so the 32x maximum overdraw makes a bit more sense...
Panajev2001a
Veteran
120 MPixels/s * 32 overdraw = ~3.8 GPixels/s so ?
Panajev2001a
Veteran
The Image cache is not the embedded frame-buffer... we have e-DRAM for that...
That e-DRAM will be needed... high resolution textures, FSAA, 3D Textures, vertex buffers ( tons of micro-polygons flowing from the Broadband Engine ) etc...
Pixel Engines: support for texture filtering ( up to tri-linear + anisotropic [256+ bits of texel data, might come in compressed format] ), up to 96-128 bits for color ( 24-32 bits per component ) and 32 bits Integer or FP Z-buffer, CLUT, S3TC or VQ ( might be done in software by the APUs... )...
What do you guys think ?
That e-DRAM will be needed... high resolution textures, FSAA, 3D Textures, vertex buffers ( tons of micro-polygons flowing from the Broadband Engine ) etc...
Pixel Engines: support for texture filtering ( up to tri-linear + anisotropic [256+ bits of texel data, might come in compressed format] ), up to 96-128 bits for color ( 24-32 bits per component ) and 32 bits Integer or FP Z-buffer, CLUT, S3TC or VQ ( might be done in software by the APUs... )...
What do you guys think ?
Panajev2001a
Veteran
Unless you are allowing each pipeline inside the Pixel Engine to work on a different triangle ( the way I see it is 4 APU for each Pixel Pipeline ) you are going to face troubles using micro-polygons...
4-8 pixel pipelines in each Pixel Engine rendering a sub-pixel or pixel size triangle ?
4-8 pixel pipelines in each Pixel Engine rendering a sub-pixel or pixel size triangle ?
Its not, if it is, they would not have put image cache and circuitry in there tightly coupled with the pixel engine.
Yes. you probably able to write back the frame buffer from the image cache to e-DRAM, but the Pixel engine should write to image cache.
If it is only 1x1 config, Pixel engine can write to the e-DRAM directly, or write to the external RAM. The Rambus stuff you mentioned gives more than enough bandwidth for 4x1 config. Once you use things for shadows. 4GPixel/s isn't alot even for 640x480.
That Pixel engine, is most likely some enhanced PS2 GS.
Panajev2001a
Veteran
Bingo
The External Rambus Yellowstone RAM will be busy enough loading data from the Blu-Ray disc and streaming it to the Broadband Engine and the Visualizer to be able to have the Pixel Engines render directly to it...
It is only 25.6 GB/s
Why would we need more than 1 pixel pipeline per Pixel Engine when most polygons could be 1 pixel or half a pixel in size ?
The Image Cache is needed to cache textures ( and from which take them and filter them... maybe they are stored uncompressed here... ) and the tile of pixels and an on-chip Z-buffer of similar size to the tile of pixels that the Pixel Engine is working on ( say 32x32 or 64x64 for the tile size in pixels ? )...
Panajev2001a
Veteran
The Image cache is too small to cache textures and a full size frame-buffer and Z-buffer...
I think it will have an on chip tile buffer and Z-buffer ( both 32x32 or 64x64 )... no deferred rendering in HW, just tiling...
I think it will have an on chip tile buffer and Z-buffer ( both 32x32 or 64x64 )... no deferred rendering in HW, just tiling...
