Hacker News Reader

Comment by revelation | Hacker News Reader

I thought modern video games are predominantly limited by GPU performance? Maybe the argument is that while usually CPU performance isn't the most important part of the equation, video gamers base their purchasing decision on misguided benchmarks that expose it.

The big CPU hog and prime candidates for these vector operations nowadays seems to be video encoding.

View on HN

Actually GPU's are bottlenecked by CPU's these days (low level API's will help a bit), GTX 1080's not to mention the Titan X are a really good example of hitting a CPU bottleneck like a brick wall at higher resolutions and higher core frequencies.

Because of the single core performance unless you are playing a really CPU intensive game which has been optimized for multiple cores (more than 4) (or running an insane SLI setup 3-4 way and need the extra PCIE lanes) the 6700K with as high overclock as possible (4.6-4.7ghz) is pretty much the bare minimum for GTX 1080 or better GPU's and even that isn't enough.

Depends on the game.

Here's Bioshock infinite: http://images.anandtech.com/graphs/graph8426/67045.png

Here is F1 2013: http://images.anandtech.com/graphs/graph8426/67044.png

So sometimes it matters almost as much as regular productivity task (like compiling software): http://media.bestofmicro.com/ext/aHR0cDovL21lZGlhLmJlc3RvZm1...

It depends on the game. Physics-heavy games for example, like Kerbal Space Program or Besiege, are usually CPU-limited.

Those are both built with Unity though, right? Where the game is basically C#. Are the actual physics even done vectorized?

C# is just a glue language, physics is run inside the engine as optimized C++, it is vectorized where possible.

Unity scripting is in C#, but the engine itself isn't necessarily written in C#. The physics are based on physx (which I assume vectorises things).

http://blogs.unity3d.com/2014/07/08/high-performance-physics...

No part of a Unity game runs in a .NET VM or any other VM. They chose C# as the scripting language because C# is one of the most popular programming languages, it's extremely popular in the non-game dev development community, and it's probably the only non-Web language that most code academies teach for traditional development maybe other than Java.

It's syntax is also pretty close to C and C++ which means developers with game dev background will feel at home as most game development is done in C++.

Unreal Engine uses Unreal Script which is now pretty much C++ but it is also not compiled directly (although with Unreal Engine 4 and onwards it's much closer to direct compile than any other scripting language).

Unity engine has it's own interpreter which then builds highly optimized C++ code and compiles it when you build the game.

Unity Engine is a pretty decent engine with kickass performance when optimized, without fine optimization any general purpose engine including Unreal 4 acts like utter crap. I'm alpha/beta testing a few UE4 games atm and you can see just how bad performance can get even on a solid defacto industry standard like UE4 like when dynamic shadows tank a GTX Titan X (Maxwell) SLI setup to below 20 fps any time there are light sources that are not properly fenced and culled - e.g. explosions.

Your last paragraph ticks me off so much about the current non-sequetor "industry standard". Most recent example I can give is that doesn't really care is EDF 4.1. It takes carpet bombing an entire city to make its FPS dip with hundreds if not thousands of gaint incest gibs (and four players) being flung across the map.

Do they really need a bazillion shaders and dynamic shadows on everything?

Unreal Engine is an industry standard when it comes to commercial general purpose engines.

There are more unreal engine titles for any given version than any other engine on the market on PC's and consoles.

On mobile unity is probably bigger atm.

You sure? I was playing with Unity back in 2009 and you scripted both game and IDE atop mono. The .NET flavour of JS was being pushed, with code examples additionally in C# and Boo (!). I preferred to use F#.

I'm surprised by how many people think Unity games are "basically C#". That's like saying Unreal Engine games are coded in Lua. Like Lua, C# is nothing but the scripting language. The Unity game engine that does all of the heavy lifting is coded in C++.

shudder unity performance....

Physics are pretty cheap unless your game is a physics simulator.

CPU performance is important when there is a lot going on (most of the frame latency is CPU side), and when the CPU's are really busy dealing with other stuff like heavy AI or tons of NPC's you get poor frame rates and scalability with GPU processing power.

Good examples of real CPU hogs would be the latest Civ games as well as games like Assassin's Creed Unity. ACU is especially a CPU killer, if your CPU OC is stable playing ACU it's really stable, I've seen that game cause CPU's that are not technically overclocked crash on their normal boost clock when the memory XPS profile was loaded.

> Physics are pretty cheap unless your game is a physics simulator.

The two games your parent named basically are physics simulators.

I'm not saying they aren't :) It's just not every type of physics. Both of them are more or less indie titles also don't expect great optimizations from them.

Minecraft is also CPU bottlenecked pretty much but that's because well the game was built with Java :)

Even though the JVM probably gets in the way of the kind of low-level optimizations we are talking about here, Java is not the main factor for the CPU usage.

All those voxels take up a good chunk (heh) of processing time. They are not all static, you know. Not sure how much of that could be shifted to the GPU.

Why can't you do physics on the GPU, anyway? The integration step is matrix-multiplication, isn't it?

You can. Nvidia bought physx, who made dedicated physics accelerators, and integrated its api into gpus for just that reason.

Occasionally you can, but it comes with caveats, even for PhysX:

• Only works on Windows

• Only works with Nvidia graphics cards (and only them, cheap nvidia card for physx + AMD card for graphics will disable PhysX)

• Not guaranteed to be faster for all cases, needs to be evaluated on a case-by-case basis

So even if the physics engine can, not all game engines use it. The Unity devs e.g. stated that they won't bother with it, as the limitations make it unattractive to pour effort into.

Collision detection and response are the hard parts and they are poorly suited for GPU implementation. Some specific cases (fluids, particles, maybe cloth) that don't require these in full work quite nicely and are used often enough (see common PhysX usage)

Sometimes, yes. Other times, no. If you're using an explicit integrator like a Runge–Kutta method such as RK4, then the answer is yes and the algorithms map pretty well onto a GPU. In that way, GPUs have been a huge boon to the scientific computing world. Though, personally, I find them a pain to program. However, if you use an implicit integrator like a backward Euler method, the answer is no because we need to solve a linear system. Yes, if we have a well defined problem it may be possible to design a custom preconditioner based on the physics of the problem that maps really well to a GPU. Those preconditioners take a huge amount of work to develop and, honestly, if you look at the last step of something like a multilevel method, it comes down to a direct factorization. Basically, direct dense and sparse factorizations do not currently map well to a GPU and these factorizations are extremely important to many scientific problems. Specifically, implicit time integrators depend on them to solve the linear systems involved and we need implicit integrators for stiff systems. Outside of integration, there are other situations where GPUs don't work well. In large scale optimization with equality constraints, there are linear systems that need to be solved and, most of the time, we need a direct factorization to solve these systems. That's why reduced spaced methods for things like parameter estimation are so popular. Basically, they're null space algorithms that eliminate the equality constraints by doing an implicit linear system solve using an explicit time integrator, which can map to something like a GPU. This leads to a host of other problems, but at least we can scale, sort of, sometimes.

At the end of the day, most scientific problems based on continuum mechanics need really fast level 1, 2, and 3 BLAS operations. That's mostly enough for simulating physics based on explicit time integrators. For elliptic problems or problems that require implicit time integrators, we need factorizations. Most of the time, we can get away with LU, Choleski, QR, and SVD. Both dense and sparse are required. For optimization with equality constraints, factorizations are also required.

By the way, if anyone wants to figure out how to do faster factorizations, dense and sparse, on whatever new hardware is coming out, that'd have an enormous impact on the scientific community. There are people working on it. There's not a lot of them.

You can. The problem is that there is a multi-frame (33ms * 2 or so) delay in getting any results back to the CPU. The GPU is set up for streaming, you compile command lists dynamically and feed it to it, this means it usually has at the very least 1 command list in execution and 1 being built on the CPU (the GPU is always kept busy, stalls are cycles going to waste). Hence the delay in getting results back.

And you will need some of those results on the CPU.

Physics for particles is not uncommon to be done on the GPU though. There is no feed-back to the CPU required so latency becomes a non-issue.

I haven't been CPU performance locked in a PC game for over 6 years - I have upgraded my GPU every 2 years and I am finally approaching the point to which I'd gain a framerate benefit from upgrading my Sandy Bridge i7 920 (I have a GTX 980 ti GPU now).

There are several outliers to this - some games are VERY cpu dependant (supreme commander, MMO's like planetside 2), and some which are EXTREMELY inefficient games (Minecraft) which require an order of magnitude more CPU power than it really needs due to architecture problems.

Big modern games are CPU limited mostly. GPU work can be scaled down very easily (even dynamically!) by reducing the rendering resolution and as such can be made to fit the limits, up to a point. Scaling the CPU side of things is a lot trickier. And although we get an increasing amount of cores in new CPUs, single core performance has not increased in the same way. Some things just don't want to be multi-threaded or must happen in-order. This then becomes the most limiting factor.

Well it is, but if your CPU is getting its job done 1ms sooner, then the GPU now has an additional 1ms to do the rendering while delivering the same deadline. Which probably means it'll render more frames.

Bottlenecking just means that improving the bottlenecked thing will result in the biggest improvement. The second-biggest performance limiter can still be a significant performance limiter.

Reply on news.ycombinator.com