PS3 Visualizer
- Thread starter vers
- Start date
Panajev2001a
Veteran
Ahem... Fafalada... I think we will not see a 4 GHz Visualizer... a 1-2 GHz chip is more probable IMHO...
Still that is 8-16 GFLOPS and 8-16 GOPS per APU and thus 32-64 GFLOPS and 32-64 GOPS per pixel pipeline...
I do not see as impossible things a ~4 GHz ( e-DRAM would be clocked at 1-2 GHz in this chip ) Broadband Engine and a 1 GHz Visualizer...
Still that is 8-16 GFLOPS and 8-16 GOPS per APU and thus 32-64 GFLOPS and 32-64 GOPS per pixel pipeline...
I do not see as impossible things a ~4 GHz ( e-DRAM would be clocked at 1-2 GHz in this chip ) Broadband Engine and a 1 GHz Visualizer...
Pana, I was talking about FLOP/cycle (outside clock speed) (that 'S' at the end of FLOP was a typo that crawled in 
). And I still assumed 1ghz at fill calc.
Either way, the point is that when you have so many ops per clock on a pixel the raw fill becomes much less of an issue.
Chap, all in good time, I am still getting my bearings with time zones and work and what not.
). And I still assumed 1ghz at fill calc.Either way, the point is that when you have so many ops per clock on a pixel the raw fill becomes much less of an issue.
Chap, all in good time, I am still getting my bearings with time zones and work and what not.
Panajev2001a
Veteran
You liar... I saw you getting your groove going that nVIDIA party babe... all break-dancing Fafalada style
That is why you are SO tired
Seriously, I agree with you on the fill-rate issue... what I think about is nthat if we used 1 pixel or half a pixel micro-polygons this power would be all for shading ( even with regular OpenGL pipeline... the Broadband Engine would do T&L )...
That is why you are SO tired
Seriously, I agree with you on the fill-rate issue... what I think about is nthat if we used 1 pixel or half a pixel micro-polygons this power would be all for shading ( even with regular OpenGL pipeline... the Broadband Engine would do T&L )...
megadrive0088
Regular
under the old way of rendering (more is better type thinking) I would agree with Vince and V3 that 4 gpixels/gtexels is not enough even at 640x480. I myself was thinking that each Pixel Engine contains many (16) or at least several (4) pixel pipelines. essentially a souped up GS. so in total, (in this speculation) the Visualizer would have 16-64 pixel pipelines. this is more like Sony. they increased their fillrate per cycle 16x going from PSX to PS2. (PSX has one pipe, PS2 has 16) so even 16-64 pixel pipelines would not be as much of an increase as from PSX to PS2 in terms of raw fillrate/number of pipes.
to equal the increase from PSX to PS2, the PS3 would need 128 pipes. that would equal the first version of the GSCube, but not the second ver! edit: no it wouldn't the first GSCube had 256 pipes (GS's 16 pipes * 16)
GSCube ver2 had a staggering 1024 pipes!
but perhaps Panajav and Faf are right on target about fillrate not being so important anymore, that the amount of stuff you do on each pixel per cycle is much more important. we shall see
still, I cannot fathom PS3 only having 4 gigapixels/gigatexels. I would also like to see Visualizer do more than 1 texture per pipe, per cycle. this was the weakness of GS. the GS had 16 pipes but wasnt even 16:1 it was 16:0.5 basicly. I forgot how it worked exactly, 8 of the pipes doing a texture for the other 8 pipes, or just a 2nd pass to get even 1 texture. not even a loopback feature.
perhaps PS3 will not use the traditional texture maps on top of polygons approach and use the emerging HLSL and/or reyeyes approach. all of this stuff i cannot even begin to understand.
All I want is more CGI-like graphics. I probably wont get what I want until PS4 anyway. bah.
to equal the increase from PSX to PS2, the PS3 would need 128 pipes. that would equal the first version of the GSCube, but not the second ver! edit: no it wouldn't the first GSCube had 256 pipes (GS's 16 pipes * 16)
GSCube ver2 had a staggering 1024 pipes!
but perhaps Panajav and Faf are right on target about fillrate not being so important anymore, that the amount of stuff you do on each pixel per cycle is much more important. we shall see
still, I cannot fathom PS3 only having 4 gigapixels/gigatexels. I would also like to see Visualizer do more than 1 texture per pipe, per cycle. this was the weakness of GS. the GS had 16 pipes but wasnt even 16:1 it was 16:0.5 basicly. I forgot how it worked exactly, 8 of the pipes doing a texture for the other 8 pipes, or just a 2nd pass to get even 1 texture. not even a loopback feature.
perhaps PS3 will not use the traditional texture maps on top of polygons approach and use the emerging HLSL and/or reyeyes approach. all of this stuff i cannot even begin to understand.
All I want is more CGI-like graphics. I probably wont get what I want until PS4 anyway. bah.
Panajev2001a
Veteran
Each Pixel Engine is likely to be working on a different polygon in its own rendering tile...
The screen is divided in tiles and each PE in the Visualizer works on one...
We work on one polygon at a time in each pipeline...
If the polygons are all, in average, 1 pixel or half a pixel in size ( using micro-polygons ) what is the point of having 16 pixel pipes GS style working on each polygon ?
What is the point of more than one or two pipelines working on each polygon ?
I understand that in the case of not using micro-polygons ( you want developers to have this option usable ) you might want to have 2 pixel per cycle for each Pixel Engine, but the HW could be underutilized when we have micro-polygons...
Unless they use it for AA... then we could justify it...
The screen is divided in tiles and each PE in the Visualizer works on one...
We work on one polygon at a time in each pipeline...
If the polygons are all, in average, 1 pixel or half a pixel in size ( using micro-polygons ) what is the point of having 16 pixel pipes GS style working on each polygon ?
What is the point of more than one or two pipelines working on each polygon ?
I understand that in the case of not using micro-polygons ( you want developers to have this option usable ) you might want to have 2 pixel per cycle for each Pixel Engine, but the HW could be underutilized when we have micro-polygons...
Unless they use it for AA... then we could justify it...
Panajev2001a
Veteran
megadrive0088
Regular
We'll also see if more pipelines are important with the upcoming R400/NV40 generation (situation with R400 is confused) if they use 16 pipelines.
A year ago, most would have said yes to 16 pipelines without much doubt. as R300 and NV30 were known to be 8 pipes and ATI talking of doubling complexity every generation. however now things are much more uncertain. ATI's R400 is up in the air from anyone's perspective except those inside ATI. they might do R390 which is thought to be a R3XX with R400 speed but without all the 400's features. or a R420 that is also less powerful than the original R400 spec. And on Nvidia's side, the pipeline counting has become foggy with the revalation that NV30 is not a true full 8 pipeline design and neither is NV35.
so things are getting interesting!
A year ago, most would have said yes to 16 pipelines without much doubt. as R300 and NV30 were known to be 8 pipes and ATI talking of doubling complexity every generation. however now things are much more uncertain. ATI's R400 is up in the air from anyone's perspective except those inside ATI. they might do R390 which is thought to be a R3XX with R400 speed but without all the 400's features. or a R420 that is also less powerful than the original R400 spec. And on Nvidia's side, the pipeline counting has become foggy with the revalation that NV30 is not a true full 8 pipeline design and neither is NV35.
so things are getting interesting!
zidane1strife
Banned
I'm kinda shocked at the fact that a 1Ghz visualizer with 4 pixel engines would be enough to handle the massive amount of stuff generated by the broadband engine...Hopefully both units will be clocked much faster, I still want 4xxx X 2xxxp rez at 120fps support, like the original future canned gs3 idea.
Panajev2001a
Veteran
Gubbi said:V3 said:
Because they might not be 1 pixel in size
If the average size is 1 pixel, then your wasting 15 pipes most of the times.
Cheers
Gubbi
You are right V3... they are actually half a pixel in size ( in some cases
) I think that the era of a series of parallel pipes all working on a single polygon will be over with Next-Generation of consoles: it is too much of a waste.
From the diagram it seems that each rendering pipeline ( each PE ) is independent from the others and thus it can work on a different polygon...
If we have games which do not push the T&L capabilities of PlayStation 3 and our average triangle size is around 2-4 pixels this is not too much of a problem ( we are still filling four different triangles at the same time ) and if the average triangle size is 1 pixel ( or lower ) we are not exactly wasting tons of resources...
4 GPixels/s can give us 4x AA at 1920x1080p at 60 fps and 8x overdraw...
Seriously, do we need MUCH more than this ?
( We are not even considering that a good chunk of opaque overdraw can be eliminated before T&L )
At 640x480p or 640x480i ( standard TV resolution ) and 60 fps we can have 16x AA and 13.5x of overdraw
Shader performance will be key ( the Visualizer should hold the Fragment Shading part in the common OpenGL pipeline, but thanks to the nature of the APUs it can be used for whatever you decide
) and the Visualizer at 1 GHz yelds 32 GFLOPS and 32 GOPS per pixel pipeline ( 32 FP ops per clock and 32 Integer ops per clock )...We have 128 FP ops per clock and 128 Integer ops per clock in total withing the whole Visualizer...
Excluding other functions like texture filtering and similar operations that are implemented with dedicated silicon...
Panajev2001a said:Gubbi said:V3 said:
Because they might not be 1 pixel in size
If the average size is 1 pixel, then your wasting 15 pipes most of the times.
Cheers
Gubbi
You are right V3... they are actually half a pixel in size ( in some cases
I think that the era of a series of parallel pipes all working on a single polygon will be over with Next-Generation of consoles: it is too much of a waste.
From the diagram it seems that each rendering pipeline ( each PE ) is independent from the others and thus it can work on a different polygon...
If we have games which do not push the T&L capabilities of PlayStation 3 and our average triangle size is around 2-4 pixels this is not too much of a problem ( we are still filling four different triangles at the same time ) and if the average triangle size is 1 pixel ( or lower ) we are not exactly wasting tons of resources...
4 GPixels/s can give us 4x AA at 1920x1080p at 60 fps and 8x overdraw...
Seriously, do we need MUCH more than this ?
( We are not even considering that a good chunk of opaque overdraw can be eliminated before T&L )
At 640x480p or 640x480i ( standard TV resolution ) and 60 fps we can have 16x AA and 13.5x of overdraw
Shader performance will be key ( the Visualizer should hold the Fragment Shading part in the common OpenGL pipeline, but thanks to the nature of the APUs it can be used for whatever you decide
We have 128 FP ops per clock and 128 Integer ops per clock in total withing the whole Visualizer...
Excluding other functions like texture filtering and similar operations that are implemented with dedicated silicon...
i guess 1080p will be easy next gen... thing is, who's gonna take advantage of it?
and, 1GHz for the visualizer? whoa i gotta get used to the fact that this thing is coming out in 2005-6...
Panajev2001a
Veteran
They could do more... maybe 1.5 GHz for the Visualizer and 3.5 GHz for the Broadband Engine...
This would increase the fill-rate and FLOPS rating of the Visualizer and while the Visualizer would be a bit more expensive, the Broadband Engine would be quite abit cheaper...
896 GFLOPS for the Broadband Engine and 192 GFLOPS for the Visualizer yelding 1+ TFLOPS
Now you guys made me think...
Hitting 4 GHz is not easy for the Broadband Engine, maybe doable, but certainly not easy...
How about clocking both chips at 2.8 GHz ( the e-DRAM should still not surpass 1 GHz of speed ) ?
716.8 GFLOPS for the Broadband Engine and 358.4 GFLOPS for the Visualizer yelding 1+ TFLOPS
This actually would be a quite NICE scenario...
We would also have a total pixel-fill rate of 11.2 GPixels/s which should make you guys happy...
This sounds actually like how the real Broadband Engine and the Visualizer chip might clock given their size and transistors' count...
The Broadband Engine and the Visualizer are veryy similar chips and the real difference between them is that in each PE of the Visualizer we take off 4 APUs to fit the Pixel Engine + Image Cache + CRTC...
This would increase the fill-rate and FLOPS rating of the Visualizer and while the Visualizer would be a bit more expensive, the Broadband Engine would be quite abit cheaper...
896 GFLOPS for the Broadband Engine and 192 GFLOPS for the Visualizer yelding 1+ TFLOPS
Now you guys made me think...
Hitting 4 GHz is not easy for the Broadband Engine, maybe doable, but certainly not easy...
How about clocking both chips at 2.8 GHz ( the e-DRAM should still not surpass 1 GHz of speed ) ?
716.8 GFLOPS for the Broadband Engine and 358.4 GFLOPS for the Visualizer yelding 1+ TFLOPS
This actually would be a quite NICE scenario...
We would also have a total pixel-fill rate of 11.2 GPixels/s which should make you guys happy...
This sounds actually like how the real Broadband Engine and the Visualizer chip might clock given their size and transistors' count...
The Broadband Engine and the Visualizer are veryy similar chips and the real difference between them is that in each PE of the Visualizer we take off 4 APUs to fit the Pixel Engine + Image Cache + CRTC...
Panajev2001a
Veteran
PlayStation 3 is not designed for REYES...
Let's just say that IMHO an architecture like that would be VERY good at it... it has everything a REYES-like renderer should have: lots of CPU power ( Integer and FP ), powerful Shading HW, lots of bandwidth for both CPU and for the GPU...
PlayStation 3 seems to be VERY flexible...
Another thing, with the polygon counts we will approach in the Next-Generation of consoles we will have lots of polygons that will average 2 or less pixels in size...
Micro-polygons also make sense as Vertex processing and Fragment Shading are going towards using unified HW and with micro-polygons you have the simplicity that all Shading is done in one single stage at the Vertex level...
Also PlayStation 2 enphasys seems to be lots of small polygons drawn very fast ( the GS likes small polygons ) and the GSCube pushed on that concept even further...
Also, I am starting to be less afraid of David Orton's statement regarding PlayStation 3...
Still if you want to do regular Vertex Shading and Fragment Shading you will be able to... that is the joy and the pain of a flexible architecture
Let's just say that IMHO an architecture like that would be VERY good at it... it has everything a REYES-like renderer should have: lots of CPU power ( Integer and FP ), powerful Shading HW, lots of bandwidth for both CPU and for the GPU...
PlayStation 3 seems to be VERY flexible...
Another thing, with the polygon counts we will approach in the Next-Generation of consoles we will have lots of polygons that will average 2 or less pixels in size...
Micro-polygons also make sense as Vertex processing and Fragment Shading are going towards using unified HW and with micro-polygons you have the simplicity that all Shading is done in one single stage at the Vertex level...
Also PlayStation 2 enphasys seems to be lots of small polygons drawn very fast ( the GS likes small polygons ) and the GSCube pushed on that concept even further...
Also, I am starting to be less afraid of David Orton's statement regarding PlayStation 3...
Still if you want to do regular Vertex Shading and Fragment Shading you will be able to... that is the joy and the pain of a flexible architecture
Panajev2001a
Veteran
Panajev2001a said:
Bump...
Panajev2001a said:
I was thinking about PSP as E3 MOTS....Moment of the show....but this one blows everything else away
...this was hot... ....even incredible power of XB cannot imitate this scene.... They used nice pixel effexts to hide some strategic places....too bad...against democray and freedom...
