High CPU Idle Rates: Why not support GPU for Better Gaming?

Discover why high CPU idle rates occur in gaming and how utilizing CPU resources can enhance your GPU performance for smoother gameplay.
High CPU Idle Rates: Why not support GPU for Better Gaming?

Table of Contents

Simply put, in a moderately sized game, both the CPU and GPU are utilized simultaneously, but they handle different tasks.

The CPU is suitable for tasks that have a sequential order. For example, if your controlled character throws a minion into a group of people, minion A will knock down minion B, and minion C will knock down minion D, creating a domino effect. Each character takes damage based on their equipment attributes and defense, and to calculate how much damage each one takes, you need to process them in order.

The GPU is suited for tasks that have no sequential relationship. Using the same example, if your character throws a minion into a group, this time, minion A knocks down minions B, C, D, E, and F all at once, and since B, C, D, E, and F are not adjacent to each other, their damage can be calculated independently and simultaneously.

However, in actual game development, it’s not so simple to separate these tasks, because before minion A hits others, you can’t know which situation will occur.

You might think, why not decide after the hit whether to use the CPU or GPU for calculations?

Here lies another issue: the CPU accesses data directly from RAM, while the GPU accesses data from VRAM. This brings up two scenarios:

  1. If the minion data is in RAM, to let the GPU perform calculations, you need to transfer the minion data from RAM to VRAM, which takes time, or vice versa.
  2. If minion data is stored in both RAM and VRAM simultaneously, one copy will be idle while the other is in use, wasting space. After calculations, you also need to synchronize and copy the results back.

The efficiency of data transfer between RAM and VRAM is very low compared to the computational efficiency of the CPU and GPU. For instance, a 1.0 GHz CPU takes about 1 nanosecond to perform an addition, while data transfer time between RAM and VRAM can be measured in microseconds or even milliseconds.

The result is that both the CPU and GPU may be underutilized, but the data bus is heavily busy, which is counterproductive.

To balance the load on the CPU and GPU, physical computations are typically assigned to the CPU, while rendering calculations are assigned to the GPU. These two data sets are mostly independent, and even when they interact, the volume is minimal. This is the most common approach in game development.

Physical computations include object collisions, rigid body dynamics, and counting how many objects there are in a game world, such as flora, monsters, and various items. If an object collides with an item, it can be picked up; if it hits flora, it can be trampled; if it collides with a monster, health may decrease, and all these calculations are handled by the CPU. Additionally, gravity and acceleration are considered.

Rendering calculations determine which objects should be displayed on the screen, their colors, proximity, size, occlusion, lighting, and shadows.

Therefore, if you find your game’s CPU is relatively idle, try adding more active units to your game. You may be pleasantly surprised to see the CPU becoming busier, and the GPU may also become more engaged, allowing you to lower graphics settings such as effects and resolution. In this case, the CPU becomes very busy while the GPU may become less engaged.

For example, in games like “Mount & Blade,” you can adjust the number of battlefield participants, and similar games can be tested for this.

End-of-DiskMFR-blog

Disclaimer:

  1. This channel does not make any representations or warranties regarding the availability, accuracy, timeliness, effectiveness, or completeness of any information posted. It hereby disclaims any liability or consequences arising from the use of the information.
  2. This channel is non-commercial and non-profit. The re-posted content does not signify endorsement of its views or responsibility for its authenticity. It does not intend to constitute any other guidance. This channel is not liable for any inaccuracies or errors in the re-posted or published information, directly or indirectly.
  3. Some data, materials, text, images, etc., used in this channel are sourced from the internet, and all reposts are duly credited to their sources. If you discover any work that infringes on your intellectual property rights or personal legal interests, please contact us, and we will promptly modify or remove it.
DiskMFR Field Sales Manager - Leo

It’s Leo Zhi. He was born on August 1987. Major in Electronic Engineering & Business English, He is an Enthusiastic professional, a responsible person, and computer hardware & software literate. Proficient in NAND flash products for more than 10 years, critical thinking skills, outstanding leadership, excellent Teamwork, and interpersonal skills.  Understanding customer technical queries and issues, providing initial analysis and solutions. If you have any queries, Please feel free to let me know, Thanks

Please let us know what you require, and you will get our reply within 24 hours.









    Our team will answer your inquiries within 24 hours.
    Your information will be kept strictly confidential.

    • Our team will answer your inquiries within 24 hours.
    • Your information will be kept strictly confidential.

    Let's Have A Chat

    Learn How We Served 100+ Global Device Brands with our Products & Get Free Sample!!!

    Email Popup Background 2