Slashdot Mirror
Ubisoft Claims CPU Specs a Limiting Factor In Assassin's Creed Unity On Consoles
MojoKid (1002251) writes A new interview with Assassin's Creed Unity senior producer Vincent Pontbriand has some gamers seeing red and others crying "told you so," after the developer revealed that the game's 900p framerate and 30 fps target on consoles is a result of weak CPU performance rather than GPU compute. "Technically we're CPU-bound," Pontbriand said. "The GPUs are really powerful, obviously the graphics look pretty good, but it's the CPU that has to process the AI, the number of NPCs we have on screen, all these systems running in parallel. We were quickly bottlenecked by that and it was a bit frustrating, because we thought that this was going to be a tenfold improvement over everything AI-wise..." This has been read by many as a rather damning referendum on the capabilities of AMD's APU that's under the hood of Sony's and Microsoft's new consoles. To some extent, that's justified; the Jaguar CPU inside both the Sony PS4 and Xbox One is a modest chip with a relatively low clock speed. Both consoles may offer eight CPU threads on paper, but games can't access all that headroom. One thread is reserved for the OS and a few more cores will be used for processing the 3D pipeline. Between the two, Ubisoft may have only had 4-5 cores for AI and other calculations — scarcely more than last gen, and the Xbox 360 and PS3 CPUs were clocked much faster than the 1.6 / 1.73GHz frequencies of their replacements.
can we please stop pretending clockspeed has anything to do with performance?
as has been said a million times
CLOCKSPEED IS ONLY FOR MEASURING APPLES WITH APPLES.
different CPU generations are INCOMPARABLE using clock speed.
so for instance a sandy bridge at 2.0 ghz is slower than a haswell at 2.0ghz, even with the same ghz number.
Benchmarking is the only way.
Boo fricking hoo. Learn to develop a game with what you have and quit yer bitching.
The best damn video game console ever was 8 bits, ran on a single core (usually), at 1.79 MHz IIRC. Gamers then logged just as many hours saving princesses, shooting aliens, and stacking blocks as what gamers do today. And guess what...they loved it. They fucking ate it up and went back for seconds and thirds. No, it wasn't photo-realistic 3D video with dolby-i-don't-give-a-crap sound and 87 button LCD-screen force feedback controllers. We didn't need it because we could have fun with what we had and didn't worry about frame rates or pixel resolutions or how many cores a OS management thread ran on vs graphics cores vs whatever.
Game designers these days, spoiled rotten little twerps that whine about everything.
Maybe you didn't target your game properly.
I think what Ubisoft is trying to say here is that it's programmers are shit, and so is it's game engine (AnvilNext). Other publishers manage to do okay, but poor old Ubisoft are stuck with this turd and can't just switch to Unreal or something more competent, so sorry guys you only get 900p on consoles.
I mean, obviously if you are CPU bound the solution is to reduce the load on the GPU by making the game render at 900p. The problem is the AI for the large number of characters in the game, so clearly reducing the pixel count will help with that.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Disclaimer: I work for Ubisoft. I did not work on the game in question and I won't comment on it.
Now, the PS3. I have a friend that's made a very good living for the last few years doing nothing but PS3 optimisation. He'd go in 3 days a week and make more than I would in a year. The PS3 setup was fiendishly complicated and difficult to wring real performance out of. Even by the end of the cycle, I'd say there were only a few games that significantly made use of the potential power that was available in the PS3. On paper, it was impressive. In practice, it was a mild nightmare. You had completely different tools than when you were making a 360 game. The compiler was different. You had to be a lot more meticulous about where data was and how you were moving it around.
I worked on the PS4 earlier this year, and it's dead easy to use. The tools integrate well into the environment, and you don't have nearly the same optimisation headaches that you did on the PS3. It's trivially faster than the XBone, and there's virtually no platform specific code (except for the obvious stuff, like connecting to the respective online services, etc.)
From a developer perspective, the PS4 is a lot nicer than the PS3. That'll mean more simultaneous releases on the PS4 and XBone, and this time there's no delay before the PS4 is at or past parity with its competition (which is more important for Sony and Sony fans, really).
That's just my opinion on the matter, but Sony really listened to the developer community when it came to tools and ease of use. It may be less interesting, but interesting generally means 'troublesome', not 'exciting' when you're writing software.
It's probably not the AI calculations related to gameplay, but Ubisoft's AI calculations related to their DRM that get highest priority in their games ...
Like a good neighbor, fsck is there
I'm an engine programmer who has been lead on 2 published titles (PC not console).
I'm pretty sure they thought of that too and already did it. One has to write multi-threaded code for these consoles since they are multi-cored and otherwise most of the resources are wasted. Multi-threaded code is really easy to arbitrarily set tick frequencies and lock contention on the rendering thread is actually lower when you set the tick frequency of things like physics and AI to a lower frequency to your FPS, especially if your FPS is not an even multiple of this frequency. We run Havok at 50hz and render at 60fps, it sounds counter-intuitive, but it looks and feels great.
The things is though, this game is obviously either GPU limited or close to becoming GPU limited. The key here is not the 30fps, which without looking at profiling results, could be equally easily explained by CPU limiting or GPU limiting, but the resolution of 900p, which the CPU should have absolutely nothing to do with. So you cannot confidently say that it is GPU limited now, but it certainly would be at 1080p, otherwise they would have just upped the res without it slowing the framerate.
The issue here is Vincent Pontbriand is probably not a technical guy. Roles between companies vary and it's hard to know who if anyone reports to a "Senior Producer". If the engine programmers reported to him, it would be possible that he was lied to, since explaining exactly why framerates are the way things are is often tiresome and complex, since bottlenecks can be in many different places in the GPU pipeline (geometry, shader, input, texture, ROP, framebuffer) and the position of the bottleneck may shift while rendering a single frame, the bottleneck can also shift between the CPU and the GPU during a singe frame if the instruction buffer fills up. As it is, they probably don't report to him, so I would say that he probably just doesn't know the whole picture.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem