GPU being bottlenecked by CPU

[Watashi]

I understand that there is a set of instructions your CPU has to run before it "tells" your GPU to render an image. To my understanding if a processor is bottlenecking a graphics card, it is because it isn't completing instructions to ask your GPU to render images fast enough. Does this sound close? can anyone maybe provide a more in depth explanation 

[nobiggieBIG]

3 minutes ago, Doomerson said:

I understand that there is a set of instructions your CPU has to run before it "tells" your GPU to render an image. To my understanding if a processor is bottlenecking a graphics card, it is because it isn't completing instructions to ask your GPU to render images fast enough. Does this sound close? can anyone maybe provide a more in depth explanation 

 

[King_of_Oz]

Close enough. Essentially, the CPU tells the GPU what to render.  A solid analogy would be if the GPU was a chef and the CPU was a waiter. The waiter tells the chef to "make pie", and then the chef makes Pie. A bottleneck would be if the waiter was a snail so that by the time the chef makes the pie it's still taking the next order.

[Watashi]

4 hours ago, King_of_Oz said:

Close enough. Essentially, the CPU tells the GPU what to render.  A solid analogy would be if the GPU was a chef and the CPU was a waiter. The waiter tells the chef to "make pie", and then the chef makes Pie. A bottleneck would be if the waiter was a snail so that by the time the chef makes the pie it's still taking the next order.

perfect analogy honestly, I understand because I've done a fair amount of restaurant work

[Mira Yurizaki]

I have a bit of a theory on this.

 

All games run in a constant loop that has a soft real-time requirement. This means that the software should complete its tasks within a given time frame, but can run with degraded performance if it does not. However, it will not run the task again if it's within the time frame. So let's say we have a game that has a requirement that all tasks must be done in 16.667ms. If it makes that time frame, great, but it's not going to process anything until the next 16.667ms tick. If it doesn't make that time frame, then it's going to use another 16.667ms period to complete the job. 

 

It's likely after the game is done with its logic, it starts sending command lists to the GPU for 3D rendering. And if the CPU still has nothing more to do with the game, it sends another set of command lists to the GPU.

 

The reason why there would be a limitation on this I would argue is for the following:

• In a multiplayer situation, it's unfair for one player with more processing power to do more things (that may or may not be beneficial anyway) than another player, even though both players easily met the hardware requirements.
• It may be impractical to the let games run as much as they want on the CPU. If, for example, your CPU can run the main Half-Life 2 loop in less than 0.05ms, that's great, but this is beyond the comprehension of humans who won't notice any difference between the twenty iterations that went on in a millisecond.

So basically what this means is how much free time the CPU has after it's done doing the game logic is how much headroom you have for frame rate performance.

[King_of_Oz]

13 hours ago, M.Yurizaki said:

I have a bit of a theory on this.

 

All games run in a constant loop that has a soft real-time requirement. This means that the software should complete its tasks within a given time frame, but can run with degraded performance if it does not. However, it will not run the task again if it's within the time frame. So let's say we have a game that has a requirement that all tasks must be done in 16.667ms. If it makes that time frame, great, but it's not going to process anything until the next 16.667ms tick. If it doesn't make that time frame, then it's going to use another 16.667ms period to complete the job. 

 

It's likely after the game is done with its logic, it starts sending command lists to the GPU for 3D rendering. And if the CPU still has nothing more to do with the game, it sends another set of command lists to the GPU.

 

The reason why there would be a limitation on this I would argue is for the following:

• In a multiplayer situation, it's unfair for one player with more processing power to do more things (that may or may not be beneficial anyway) than another player, even though both players easily met the hardware requirements.
• It may be impractical to the let games run as much as they want on the CPU. If, for example, your CPU can run the main Half-Life 2 loop in less than 0.05ms, that's great, but this is beyond the comprehension of humans who won't notice any difference between the twenty iterations that went on in a millisecond.

So basically what this means is how much free time the CPU has after it's done doing the game logic is how much headroom you have for frame rate performance.

I am a game developer, and I am here to tell you that that is somewhat true.

 

Most games have what is called a "Start() method", which is a set of code that is called once per frame. Therefore if your game runs at a low FPS, the Start() method will be called less frequently, and therefore less preformance. It does not, however, matter what time frame the start() method is called.

 

 

If you want to read some nitty-gritty on the subject, I have provided a link to the Unity Game Engine documentation below:

 

https://docs.unity3d.com/ScriptReference/MonoBehaviour.Start.html

[King_of_Oz]

On 2017-03-09 at 8:20 AM, King_of_Oz said:

I am a game developer, and I am here to tell you that that is somewhat true.

 

Most games have what is called a "Start() method", which is a set of code that is called once per frame. Therefore if your game runs at a low FPS, the Start() method will be called less frequently, and therefore less preformance. It does not, however, matter what time frame the start() method is called.

 

 

If you want to read some nitty-gritty on the subject, I have provided a link to the Unity Game Engine documentation below:

 

https://docs.unity3d.com/ScriptReference/MonoBehaviour.Start.html

Oh, dear. I am an idiot. I just realized that what I told you is wrong. It's called an  "Update() method" not start. That unity documentation page is the wrong one. Here is the correct one:

 

https://docs.unity3d.com/ScriptReference/MonoBehaviour.Update.html