[QUOTE="hexashadow13"][QUOTE="04dcarraher"] Wrong, a 7800GT would be able to to run UC 2 and at better graphical settings if they spend time coding the game to that hardware. Console optiminization also means alot of cutting and toning down quality in items, textures resolutions etc. If PS3 had a normal Geforce 7800 gpu with full specs(RSX is a gimped G70 chipset) and 512mb of video memory UC 2 would look alot better, UC 2 isnt all that great looking in all aspects. ronvalencia
But then it would only work that way on a Geforce 7800 and not other cards. And I highly doubt it could be ported in the first place without the PS3s SPUs. Most of the power for the best looking PS3 games comes from them. Not the GPU. This is wrong i.e. refer to PS3's LinuxPPC+SPUs only setup.You only have 6 SPUs to play with.Sony(SCEA)'s studypaper on "Deferred Pixel Shading on the Playstation 3" and comparative performance to Geforce 7800 GTX. Can be found from http://research.scea.com/ps3_deferred_shading.pdf
Quote
D. Comparison to GeForce 7800 GTX GPU
We implemented the same algorithm on a high end state of
the art GPU, the NVIDIA GeForce 7800 GTX running in a
Linux workstation. This GPU has 24 fragment shader
pipelines running at 430 Mhz and processes 24 fragments
in parallel. By comparison the 5 SPEs that we used process
20 pixels in parallel in quad-SIMD form.
The GeForce required 11.1 ms to complete the shading
operation. In comparison the Cell/B.E. required 11.65 ms
including the DMA waiting time
From Sony's own words, 5 SPEs(with DMA) is roughly equal to Geforce 7800 GTX. RSX has slightly clocked higher than G70 i.e. near G71.
A real game will include texture fetch operations i.e. it will slow down RSX/G7X.
IBM leaders discuss the future of gaming
GPUs vs Cell
Blogged under Cell by Barry Minor on Wednesday 30 November 2005 at 7:39 pm
Recently I came across a link on http://www.gpgpu.org that I found interesting. It described a method of ray-tracing quaternion Julia fractals using the floating point power in graphics processing units (GPUs). The author of the GPU code , Keenan Crane, stated that "This kind of algorithm is pretty much ideal for the GPU - extremely high arithmetic intensity and almost zero bandwidth usage". I thought it would be interesting to port this Nvidia CG code to the Cell processor, using the public SDK, and see how it performs given that it was ideal for a GPU. First we directly translated the CG code line for line to C + SPE intrinsics. All the CG code structures and data types were maintained. Then we wrote a CG framework to execute this shader for Cell that included a backend image compression and network delivery layer for the finished images. To our surprise, well not really, we found that using only 7 SPEs for rendering a 3.2 GHz Cell chip could out run an Nvidia 7800 GT OC card at this task by about 30%. We reserved one SPE for the image compression and delivery task. Furthermore the way CG structures it SIMD computation is inefficient as it causes large percentages of the code to execute in scalar mode.This is due to the way they structure their vector data, AOS vs SOA. By converting this CG shader from AOS to SOA form, SIMD utilization was much higher which resulted in Cell out performing the Nvidia 7800 by a factor of 5 - 6x using only 7 SPEs for rendering. Given that the Nvidia 7800 GT is listed as having 313 GFLOPs of computational power and seven 3.2 GHz SPEs only have 179.2 GFLOPs this seems impossible but then again maybe we should start reading more white papers and less marketing hype.
This is a nice read on Cell and Raytracing and how Cell was able to out ran a 7800GT OC by 30% when Cell alone could only do 179.2 Gflops and the 7800gt OC can do 313 Gflops.
GameTomorrow
IBM leaders discuss the future of gaming
Beyond Polygons
Blogged under Uncategorized, Cell by Barry Minor on Tuesday 26 July 2005 at 10:45 pm
First let me introduce myself. My name is Barry Minor and I have been on the Cell processor project since the fall of 2000. Before Cell I developed 3D graphics processors for IBM and Diamond under the FireGL brand.
Cell has been a great project and from the beginning we have focused the architecture around graphics and video processing. Once we had the architecture locked down I started writing a real-time ray-caster for Cell optimized around height-maps. As the design of the renderer progressed it became very apparent that Cell was not just good but stellar at such tasks. We found that we could ray-cast 720P images (1280×720) of complex scenes at frame rates greater than 30 frames/sec with a single Cell processors (50x a G5 VMX processor) and double that rate with a two way SMP configuration. Cell has the potential to move a new clas of previously off-line rendering algorithms to real-time speeds thereby pushing us beyond polygon rasterization.
I think you will initially see hybrid approaches where backgrounds are rendered with ray-casting and foregrounds are rendered with GPU rasterized polygons but with the focus of people like Philipp Slusallek full blown real-time ray-tracing on Cell will be a reality.
This is the real difference Cell it was build for graphics and video processing.
Log in to comment