Can someone explain me why ...

[pc999]

Is GoW (UE3?) using so litle the XeCPU?

Looking at this, we see on slide 17 that the game is only using ~5,5 gflops ie less than 10% of a flops intensive/friendly CPU architeture.

Once this is a game made for some good time ago for this machine in specific I would guess that it would be prepared for the machine, so this is not because they are worried with single core P4s that must run it.

Anyone knows why are they pushing so litle from it (its FPUs?)?

Thanks in advance.

 

[Titanio]

I don't think those numbers relate to any particular game. I think they're just meant to illustrate the relative demands of different types of code in a 'typical' game, or typical UE3 game perhaps.

 

[Powderkeg]

They don't need to use more in order to make the game do what they want.



And that's true of just about every game on almost any system. The day games are made to use the full processing power without any thought given to the need to do so will be the day you stop playing games and start watching nothing but tech demos.

 

[pc999]

I don't think those numbers relate to any particular game. I think they're just meant to illustrate the relative demands of different types of code in a 'typical' game, or typical UE3 game perhaps.

If so I guess it will take a good while till UE3 games push something ven near the 20% of the CPU.

They don't need to use more in order to make the game do what they want.

Then why they still cant have good fremerate (not even talking about 60FPS great for gameplay), none complained about the BW, memory (in fact they have 2x than expected) or the GPU, also the could really use better animation (more physics would be a big plus too).




Wouldnt this mean that the game would fly on a (single core) PC (or even a 2x faster XCPU) that can do much more than this and flops is the only advantage of XeCPU.

 

[Titanio]

If so I guess it will take a good while till UE3 games push something ven near the 20% of the CPU.

It's going to be very dependent on the game. There really is no such thing as a typical game, I wouldn't read too much into these numbers. He was just giving a rough idea of the relative computational intensity of different types of code (and using fp to do that, which wouldn't necessarily cover everything the CPU was doing anyway).

 

[Powderkeg]

Then why they still cant have good fremerate (not even talking about 60FPS great for gameplay), none complained about the BW, memory (in fact they have 2x than expected) or the GPU, also the could really use better animation (more physics would be a big plus too).

Since when did your frame rate depend exclusively on the FLOP output of your CPU?

And what evidence do you have that the final version of GOW will have frame rate problems?

Wouldnt this mean that the game would fly on a (single core) PC (or even a 2x faster XCPU) that can do much more than this and flops is the only advantage of XeCPU.

This means nothing if the limiting factor of performance is the memory bandwidth. If that's the case then you can put any CPU you want in there and it wouldn't make a bit of difference.

 

[blakjedi]

Sweeney explicitly states that they are getting roughly 500 GFlops of processing out of the Xenos right now!? How is that possible?

 

[Jesus2006]

Sweeney explicitly states that they are getting roughly 500 GFlops of processing out of the Xenos right now!? How is that possible?

He's not talking explicitly about the Xenos there, but about the demands of the UE3 (on all platforms) in general. And 500 Gflops sounds much, but it's quite easily achievable counting shader ops.

 

[pc999]

He's not talking explicitly about the Xenos there, but about the demands of the UE3 (on all platforms) in general.

I guess this is also the reason why there is so litle usage of CPU FPUs too. Also those 500Gflops are for 720p at lower rez it should much less so easly scalable.

I guess that meybe UE3 is not that demanding after all.

 

[blakjedi]

He's not talking explicitly about the Xenos there, but about the demands of the UE3 (on all platforms) in general. And 500 Gflops sounds much, but it's quite easily achievable counting shader ops.

uhh... slide 45 says ""Proof": Xbox360 games are running with 48wide data shader programs utilizing half a Teraflop of compute power..."

on slide 51 it then points out that of 505.5 gigaflops used for their games, 500 are just on the GPU for shading...

 

[pc999]

uhh... slide 45 says ""Proof": Xbox360 games are running with 48wide data shader programs utilizing half a Teraflop of compute power..."

on slide 51 it then points out that of 505.5 gigaflops used for their games, 500 are just on the GPU for shading...

It can do 1 teraflop (althought just 2xx programable, pety we dont know how many used) and it is supossed to be easy to use, very high on efficience (unified shaders) and it is a relatively well know API. Plus flops isnt everything, they dont use tiling, memoexpor, tesselation so I would say they still have a lot to explore

 

[scificube]

This ppt is fairly old I think, and that it's more about detailing the challenges programming languages present currently to producing "parallelized code" than outlining how resources are used with UE3.0 on any particular platform. Though Gears of War is mentioned frequently the other platforms do make it into the text and UT2007 even grabs a still or two for itself. I also wonder how much has changed since this presentation over at EPIC.

Anyway...

When it comes to just how much and how the CPU is being used or rather back then one has to remember CPUs like Xenon and Cell did not exist as UE3.0' core technology was being developed and that taking advantage of these parts would be the task of "game code" at present as a result. Even with UE3.0 targeting concurrent multi-threading in the feature set I would still say this is true. Also, Gears of War and UT2007 have been in development for quite some time. Gears of War especially - or at least some of the technology leveraged in it - has been on display in the form of tech demos going back to when the 6800 was introduced. (I'd imagine the core tech shown is applicable to PC, X360, and PS3 all the same.)

I feel the simplest answer to the question is that Epic along with most every other developer simply aren't at a stage where they can fully leverage either Xenon or Cell. IIRC Epic only recently got their multi-threaded renderer up and running for UE3.0 games as a example. The fact that Tim Sweeny speaks to problems with synchronization, and maintaining the proper state of objects sort of proves there is still work to be done even though his comments are more aimed at the limitations of C than directly not understanding how to solve the problems at hand. IIRC there was a discussion here on B3D about Tim's proposed improvemtents...or should I refer to them as Haskell's?

When developers have banged out how to effectively and efficiently use the CPUs in the consoles then I expect flop usage to go up as developers require..."need" being the critical point of course but that has already been addressed in this thread. Who knows....maybe Tim will get his wish or make it come true himself by implementing a language more amenable to concurrently executed multi-threaded code.

 

[Shifty Geezer]

I supposed a plugin Havok or PhysX physics engine would nicely gobble up CPU power and not feature as a requirement of the UE3 engine. 5 GFlops is a lot compared to conventional x86 processors too, and a engine that needs lots more maths power wouldn't port to PC well.

 

[Fox5]

I supposed a plugin Havok or PhysX physics engine would nicely gobble up CPU power and not feature as a requirement of the UE3 engine. 5 GFlops is a lot compared to conventional x86 processors too, and a engine that needs lots more maths power wouldn't port to PC well.

What if 5 gigaflops is the most performance they can get out of Xenon right now?
What if a PC can run the same code with less? (not that I think any shipping processor right now has less, a 3ghz p4 is about the slowest you find on the market nowadays)

 

[Gubbi]

Or what if the engine is currently 100% CPU limited, and that theoretical peak flops has near *zero* correlation to actual performance.

Cheers