-1
\$\begingroup\$

Maybe my question sounds naive because I'm not a game developer but I dont see objective reasons for this. An average cpu is in times more powerful than an average gpu like a few graphics cards in one.

The most repeated reasons in internet:

the GPU isn't as busy as the CPU

If the gpu renders the screen how it can not be busy The modern cpus are powerful enough. They are not busy most of time. For example my cpu's usage is 3%.

many GPU's are designed to process graphics commands in parallel, CPU single threads them

What bothers the games to run a few parallel processes even on one cpu core? In my opinion its not correct to tell that the gpu is better if games never use 100% of the cpu's capacity. To be specific they dont use even 50%.


To clarify my question based on responses in the comments:

Did you mean to ask "Why do games render more slowly on the CPU?"

Yes I mean why the cpu cant do the whole work for games when it is underloaded and especially if it does the largest part of work in any case.

You can not compare GPUs and CPUs directly, because they do different things.

What bothers them to do the same things?

The CPU isn't as well suited to performing rendering calculations

I dont understand what "suited" means. And why the cpu is not suitable for primitive tasks aka paint roller.

adding additional parallel processes doesn't improve performance

Then why do you produce multicore graphics cards and multicore central processing units? Just give various parts of one task to a few processes if one process is slow and 100% of the capacity is not used. What bothers to emulate the gpu?

Its also unclear for me why when you play without a separate graphics module the games see only one cpu core when you play with the gpu they see and use all the cpu cores. May be some magic.

\$\endgroup\$
8
  • \$\begingroup\$ It is not true that 'games never use 100% of the cpu's capacity'. It depends both on the CPU and on the game. \$\endgroup\$ – Sacha Jun 11 at 7:28
  • \$\begingroup\$ This is a bit like asking "Why can't an indie studio of four people churn out a AAA project as quickly as a studio with hundreds or thousands of people?" — fewer cores ≈ fewer people to split the work between. \$\endgroup\$ – DMGregory Jun 11 at 11:22
  • \$\begingroup\$ "In my opinion its not correct..." - doesn't matter; opinion is irrelevant in the face of 25 years of existence-proof that GPUs are just better suited for certain types of processing tasks. \$\endgroup\$ – Maximus Minimus Jun 11 at 14:31
  • 1
    \$\begingroup\$ It looks like you accidentally created a second account also named "Guest". Follow the directions here to merge your accounts and regain control of your question so you can edit it or post comments on answers if you need anything clarified. \$\endgroup\$ – DMGregory Jun 12 at 12:05
  • 1
    \$\begingroup\$ Overall I think this is a very interesting topic but a really poorly asked question. I think the OP should clear out some confusion, read the current answers and try to sum up his concern in a more comprehensive way. \$\endgroup\$ – Sacha Jun 13 at 21:16
4
\$\begingroup\$

You can not compare GPUs and CPUs directly, because they do different things. You can't say that one is a "more powerful" computing device than the other because they are specialized in different things.

GPUs are specialized in performing short and linear programs on large datasets. These programs are called "shaders" which is a term you might have heard of before. Most of them are just a handful lines of code. For example, a pixel shader might take a million of pixels and for each one sample the RGB color value of a texture, calculate the proximity to the nearest light source and multiply it with that.

CPUs are specialized in performing large and complex programs with very large amount of code full of complex instructions and lots of diverging paths. And they usually run that code on data which is a lot more heterogeneous.

While the GPU's shader operates on a million pixels, the CPU performs on the same frame all this:

  • Query the state of physical devices like mouse and keyboards
  • Parse a 3d model file streamed from the filesystem and transform it into a format the GPU can work with
  • Route finding for 20 enemies
  • Calculate Sizes and positions of 23 UI elements
  • Execute the AI behaviors for 54 enemies
  • Calculate the trajectories of 162 projectiles
  • Check for collisions, which means to perform calculations with hundreds of mobile and thousands of immobile geometric shapes to find out if any of them intersect.
  • Check the health of 232 entities in the game
  • Notice that one of them has below 0 health, remove it from the game, update various data structures indexing entities, check if there are any events which need to be executed on the destruction of that entity and execute those events
  • And lots and lots and lots and LOTS of other things.

All of that stuff can require tens of thousands of lines of code which need to be executed every single frame, and another hundreds of thousands which might get executed.

As you can see, they are very different computing device optimized for very different tasks. Some games require more work from the GPU, which means the CPU will have some idle time while you play. Other games might have less computationally intense graphics and more computationally intense gameplay, so they will be CPU bound, which means that the GPU won't run at full capacity while the CPU gets to its limit (or at least one of its cores - the limits of CPU multithreading are a different and also very complex topic).

Or to use an analogy: Think of the GPU as a paint roller and the CPU as a paint brush. The roller lets you get a lot of paint on the wall quickly, but it lacks finesse. You can only use it for large, even surfaces. A paint brush gets you fewer paint on the surface at the same time, but it is a much more flexible tool. It is far better at taking care of small details, uneven surfaces and hard to reach places. They are both tools for painting, just like GPU and CPU are tools for computing. But while they both seem to do the same thing, one tool is not superior to the other. They are tools with different strengths and weaknesses which compliment each other. And if you want to be an efficient painter / game developer, you need both of them. Depending on the project ahead of you and the unique challenges it poses, one tool might see a lot more use than the other. But you better have both of them in your toolbox and know how to use them and when to use them.

\$\endgroup\$
2
\$\begingroup\$

Generally speaking, a game doesn't execute on a GPU, it executes on the CPU & the rendering executes on the GPU. The GPU is specialized to execute graphics related calculations whereas the CPU is designed for more general purpose calculation. For games that use a GPU instead of the CPU for rendering, the CPU is still necessary for executing everything else. When you run have a game that renders using the CPU instead of the GPU, you have two main disadvantages:

  1. The CPU is doing more work than it would if the rendering calculations were being handed off to the GPU.
  2. The CPU isn't as well suited to performing rendering calculations as a GPU (of equivalent vintage anyway; a modern CPU might be able emulate a significantly older GPU in some cases without any trouble).

Regarding parallel processes, some games do use parallelization to improve performance. But the gains aren't linear, meaning past some point, adding additional parallel processes doesn't improve performance. But it increases complexity, making the code harder to design, maintain & fix. Parallelization is a tool that is used when it makes sense, but it's not a silver bullet solution for improving performance.

\$\endgroup\$
2
\$\begingroup\$

Design differences

The CPU isn't as well suited to performing rendering calculations

I dont understand what "suited" means.

Think about a CPU like a 4x4 - it can go anywhere, but it isn't necessarily the fastest or most fuel efficient thing in the world. A CPU can do anything, go anywhere. But it's not a racing car.

Think about a GPU like a drag racing car - it can go very fast, but it can't change direction quickly. And it can't go offroad, nor can it climb a steep hill.

These two cars are designed for completely different purposes. Why shouldn't this be the same for any other machine? DISCLAIMER: Sure, this is not a perfect analogy, but it makes the point.

Here's one of the most important differences. When there is a conditional branch (if or switch) in code, a CPU is designed to handle that in the most efficient way possible. A GPU works differently. It expects to be able to pipeline information similarly across all of its cores.

So let's say you have an if statement in a shader. This means that if one core / thread fails to return true, the others are all held up, because GPU threads work in lockstep, unlike on the CPU. (Actually, one if statement is often okay, but the deeper you go, the more this fragments the workload so that the GPU is unable to create an efficient dataflow.) For something like your paint roller which doesn't require a lot of if statements, but just to paint the whole screen quickly, this works very well.

Now let's consider giving a CPU the same task. Every CPU core is hugely more complex in it's design (both in itself and within the context of its parent CPU's design) than a typical GPU thread. Guess what the downside is? OVERHEAD. There is overhead for branch prediction, there is an overhead dependent on cache regime complexity, there is an overhead for SSE/AVX/MMX, etc. etc. etc. There are probably hundreds of features. Every time you assign a thread to a CPU core, there is a startup and shutdown cost that can be many CPU cycles (which are lost for processing your code). On the GPU, any overhead to startup or shutdown is mitigated (amortised) by the fact that when you start one thread, you are starting several hundred others, as well, so cost becomes negligible.

In STEM, hybrid solutions often come out better than "pure" solutions - for effectiveness, cost and/or efficiency.

Cost of manufacture

It is true that a CPU could do anything, if it had enough cores. (You could say a GPU is not so capable, mainly because of a lack of branch prediction.) Cost per CPU core has traditionally been on the order of 10s-100x more costly than GPU cores. The reason is that these cores are fare more full-featured. They typically have multiple levels of cache, branch prediction, vectorisation, and many other features. Per se, a CPU has traditionally been massively more complex than a GPU. A GPU consists of a lot more repitition than of the systemic complexity than a CPU.

So if you could buy 1 car engine vs. 10 motorcycle engines that apply twice the power for half the cost and weight, which would you buy? It would depend on many factors, such as power vs torque rating, engine wear and maintainability, acceleration curve, weight etc. Similar principles apply here.

In the real world, money talks. If Option A manufacturing setup costs me 10x, 5x, or even 2x to get the same quality product as Option B, why would I choose option A? At the end of the day, that cost has to go the consumer, which means to do the same tasks we do today on CPU + GPU, in the world you have proposed, we would have been paying maybe 5x-20x more for a CPU that can literally do everything, for the last 20 years. Would that have been worth it?

Efficiency of code

Its also unclear for me why when you play without a separate graphics module the games see only one cpu core when you play with the gpu they see and use all the cpu cores. May be some magic.

Sure, some people and companies write inefficient code. Alternatively, you're comparing a game from 20 years ago, with one made today. Some technical developers can produce very high quality optimised code, usually due to (1) a deep understanding of complex CPU architecture, and (2) a lot of time spent in low-level optimisation.

The industry has sped up since the early 2000s, CPUs and GPUs have become a lot more powerful and thus able to carry a bigger load, and consequently many developers no longer give as much attention to deep optimisation as they may once have done. It often just isn't economically viable in today's fast-paced and highly competitive world, to optimise so much. Whereas before year 2000, you had no choice if you wanted to write a game that could run reasonably well.

\$\endgroup\$
-1
\$\begingroup\$

Most CPUs have a lower-end GPU Unit with a fewer number of computing units and less memory and bandwidth. Modern video games come with complex shaders, higher numbers of primitives and volumetrics, and so on. Rendering such perplexed programs and other things would be a headache for CPU, even today.

On the other hand, CPU cores aren't designed for rendering geometries. They are able to, but numerous times slower than a GPU can. In addition, information from the G-buffer (as most of the modern AAA titles are using 4K and 8K textures), which including base color, normals, roughness and AO, combine to make a massive load of data to load into the VRAM.

More often there are obvious visual artifacts that occur which more like low draw distance and object disappearance if the video game running on a CPU rather than a dedicated GPU. Rendering merely with a CPU is impracticable. If you are familiar with SwiftShader how performing well on low-end PC's, swift shader which meant to render games based on Software wisely to cope with CPU

\$\endgroup\$
0

Not the answer you're looking for? Browse other questions tagged or ask your own question.