MikeB on 17 August 2007
@ omgwtfbbq
huh? WTF are you talking about? I never compared Xenon to Cell for graphics processing. That would be a ridiculous comparison to make, not to mention completely useless.The correct comparison would be comparing the two graphics cards,
It's not as black and white like you write. It's not Cell vs Xenon and RSX vs Xenos. In the PS3 and XBox 360 it's Cell+RSX+other factors (higher speed XDR memory, higher internal bandwidths, ultra high speed local SPE memory, etc) vs Xenon+Xenos+other factors from a hardware perspective.
and from what I heard Xenos outperforms RSX in most cases.
Looking solely at the graphics chips in raw numbers the RSX is far more powerful, but the Xenos offers more flexibility and some nice hardware tricks. So let's say they are about on par.
So please explain how the number of cores in the CPU could possibly relate to how well the GPU performs.
For example the SPEs can take workload off the GPU, allowing the GPU to focuss on other things. Some examples:
The people behind F1 CE:
The SPUs are heavily involved in the graphics pipeline and do an enormous amount of work to eliminate inefficiency before anything arrives at the PPU and RSX. For example, the SPUs are powerful enough to decompress and check every triangle [polygon] before passing it on to the RSX. Triangles that are facing away from the player, or that are not on the screen can be 'trimmed' away by the SPUs, which hugely reduces the amount of redundant work sent to the RSX. This in turn lets the RSX get on with what it does best--drawing stuff on screen.
The SPUs can also be used to augment the RSX vertex shaders, making far more vertex-heavy tasks possible which is very useful for character animation. Additionally, the SPUs can be used to implement behavior very similar to geometry shaders--F1 CE uses them in this way to render seamless interpolated levels of detail for some scene elements. So in answer to the question "Do the Cell and RSX work together?" the answer is a resounding "Yes," and I think this is one of the real strengths of Playstation 3 that we'll see increasingly exploited by development teams going forward.
The SPUs can also be used to augment the RSX vertex shaders, making far more vertex-heavy tasks possible which is very useful for character animation. Additionally, the SPUs can be used to implement behavior very similar to geometry shaders--F1 CE uses them in this way to render seamless interpolated levels of detail for some scene elements. So in answer to the question "Do the Cell and RSX work together?" the answer is a resounding "Yes," and I think this is one of the real strengths of Playstation 3 that we'll see increasingly exploited by development teams going forward.
The people behind Motorstorm:
If by “cooperative rendering” you’re referring to SPUs supporting the RSX, I strongly believe that this approach will become far more widespread. In addition to reducing the vertex load on the RSX through the use of culling and vertex pre-processing, this approach also provides an efficient mechanism to introduce procedural geometry.
Historically, CPUs have provided course grain scene culling using view frustums, occlusion planes, portal visibility and BSP-trees with GPUs left to perform fine grain rejection using guard band clipping, occlusion and backface culling. While such features improve fragment performance, they don’t reduce vertex processing overhead.
The leap in performance provided by Cell gives us the bandwidth to significantly reduce RSX time spent processing vertices that don’t contribute to the final scene. The favoured approach is to use SPUs to generate minimal scene/instance specific index and vertex buffers from compressed data.
Historically, CPUs have provided course grain scene culling using view frustums, occlusion planes, portal visibility and BSP-trees with GPUs left to perform fine grain rejection using guard band clipping, occlusion and backface culling. While such features improve fragment performance, they don’t reduce vertex processing overhead.
The leap in performance provided by Cell gives us the bandwidth to significantly reduce RSX time spent processing vertices that don’t contribute to the final scene. The favoured approach is to use SPUs to generate minimal scene/instance specific index and vertex buffers from compressed data.
"David Kirk: SPE and RSX can work together. SPE can preprocess graphics data in the main memory or postprocess rendering results sent from RSX.
Nishikawa: for example, when you have to create a lake scene by multi-pass rendering with plural render targets, SPE can render a reflection map while RSX does other things. Since a reflection map requires less precision it's not much of overhead even though you have to load related data in both the main RAM and VRAM. It works like SLI by SPE and RSX.
David Kirk: Post-effects such as motion blur, simulation for depth of field, bloom effect in HDR rendering, can be done by SPE processing RSX-rendered results.
Nishikawa: RSX renders a scene in the main RAM then SPEs add effects to frames in it. Or, you can synthesize SPE-created frames with an RSX-rendered frame.
David Kirk: Let SPEs do vertex-processing then let RSX render it.
Nishikawa: You can implement a collision-aware tesselator and dynamic LOD by SPE.
David Kirk: SPE and GPU work together, which allows physics simulation to interact with graphics.
Nishikawa: For expression of water wavelets, a normal map can be generated by pulse physics simulation with a height map texture. This job is done in SPE and RSX in parallel""
