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 (
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.