Now is that the PS3 version or the 360 version? (i have a feeling this is so gonna happen. Kojima is just screwing with our heads as usual.) black_awpN1
the 360 can't handle what Hideo Kojima is planning to do with the PS3 MGS4, sorry to say. so i think that if you're excited about seeing MGS4 on your 360, you're going to be really disappointed. he already insulted the 360, calling it nothing more than a dvd player when he called it "dvd level" while he calls the PS3 "the theater. MGS4 is aimed at the theater." and if you want proof of that just ask for the link ;) you have to understand that as time goes by and developers get more and more familiar with the PS3 hardware, PS3 games will indeed look better than 360 games. i don't know if i should be posting this here but first off, here's that link..
http://kotaku.com/gaming/go307/feature-talkin-metal-gear-with-hideo-kojima-248695.php
and now..
(originally posted by ATrillionaire on a different thread)
Posted by a developer on another forum who has worked with both the PS3 and the Xbox 360: Â
"Cell is, as many of you know (and if you do skip this paragraph), a combination of a dual threaded PPU with 8 SPU's. The Cell within the ps3 is limited to 7 to bring yield up and a further 1.5SPU's are used by the system itself providing the "console" programmer with access to 5.5. If the proper system is used then 5.5 can actually be used.
Given 5.5 SPU's each with 256kb of memory on chip with zero latency the programmer is capable of essentially writing a script for an spu. That script will run with little or no input from the PPU. Consider this example running on the Xenon (xbox 360).
you want to render a character in the range of 20,000 polygons. He animates, he has advanced lighting, he uses morphing for his muscles & facial expression and he's being rendered in split screen. So we have
Morph Each Vert - on the CPU
Skin (animate) Each Vert - on the CPU
Render 20,000 polys for Viewport 0's shadow - directly on the GPU
Render 20,000 polys for Viewport 0's main - directly on the GPU
Render 20,000 polys for Viewport 1's shadow - directly on the GPU
Render 20,000 polys for Viewport 1's main - directly on the GPU
so from the "systems" point of view (POV) you've passed over the entire vertex set twice with progressively more complex systems. You then send that data to the GPU four times to render shadow & main viewport for each viewport.
Now consider that the system will normally not render faces we can't see (facing away). For an average model around 50% of the faces cannot be seen. Sadly a GPU cannot tell if a face can be seen or not until its actually processed the verts themselves.
If we assume each poly uses 3 new verts then we have the following data pattern.
2x60,000 verts processed on the CPU
4x20,000 polys rendered, touching 240,000 verts in the process - on the GPU.
factoring in that we can't see 50% of the faces we have
2x60,000 verts processed on the CPU
4x20,000 polys rendered, touching 240,000 verts in the process, rendering 4x10,000 polys.
120,000 vert processes on CPU
80,000 polys rendered using 240,000 vertex accesses.
The CPU has limitations. All its memory access goes through a shared L2 cache (1MB) meaning even if we move this process off to a different thread the execution of this code WILL both affect the other threads (Slow them down) AND be affected by other threads itself. In short it will be memory access bound across the board.
Further to that the GPU has to read each element of a vertex into its local cache before it can decide to render or not. Assume each read of a parameter takes 1 cycle, most polys use at least (Position, Normal, Binrm, UV's, Cols) so conservatively we'd be seeing 5 attributes read in... 5 cycles per vertex.'
These numbers are building.... in short its not a quick process.
Now - consider leveraging a single SPU to do this work.
Morph Each Vert - on an SPU
requires the data to be DMA'd in from main memory (zero cache problems)
Skin (animate) Each Vert - on the SPU at the same time
data is already in the local spu memory, no dma required, no cache issues
now consider that the spu itself is faster at executing vector code in general so the above processing without memory concerns is already at least twice as fast as the PPU on both machines. Factor in zero memory latency and what you end up with is the same process as 360, running twice the speed with zero memory issues and having zero affect on any and all other code running on the system - its quick.
It gets better.
The spu's are great at data processing as exemplified above. Previously we would have sent all 80,000 polys to the GPU for rendering BUT the spu's can help out here. We already stated that roughly 50% of the verts can't be seen as they face the wrong way.... the spu can remove these verts VERY quickly with no issues and no affect on any other system. So at the cost of a small amount of spu time we remove all the polys we cannot see and upload to the GPU only what actually needs to render.
Using this type of setup the SPU's can be used to help out the GPU. Because the SPU's are so versatile I would predict that within a few generations of games we'll start seeing graphics more advanced on ps3 than we will on 360.
SPU's are a very under-utilised element of ps3 in current gen games and those that do use them use them in almost niave ways; we will get better."
___________________________________________________________________________
just to make short...
"Using this type of setup the SPU's can be used to help out the GPU. Because the SPU's are so versatile I would predict that within a few generations of games we'll start seeing graphics more advanced on PS3 than we will on 360."
lol :D
Â
Log in to comment