Ambiera ForumDiscussions, Help and Support. |
|
|
|||||
|
Recently I noticed that running CopperCube games in windowed mode loads one CPU thread to 100% on ryzen hx 370. The game runs smooth at 60fps, but it is really weird, especially considering it doesn't load the same CPU in fullscreen mode at all. Did anyone noticed something similar, is there any workaround for it? |
||||
|
It doesn't do that when in fullscreen mode? |
||||
|
Nope, only if windowed. I also thought it might be an issue with fps number being too high, so checked the limit - it is set to 60. Vertical sync also doesn't affect that. And it happens even with base scene with only cube and skybox. |
||||
|
Check if the unusual CPU usage is caused by a specific module loaded in the game process. Examine the CopperCube game process using "Process Explorer" (part of the "Windows Sysinternals Tools", download the tool directly from Microsoft, Process Explorer v17.11). - Launch your game exe - Launch Process Explorer (procexp.exe) - In Process Explorer, find your game process in the process tree - Right-click on the game process, select "Properties" - In the "Properties" window, go to the "Threads" tab. This should show a table of all active threads in the game process. - The "CPU" and "Start Address" columns are relevant in the context of this problem - When the game window is not in focus, the CPU usage of the active threads should be close to zero. This appears to be the intended behavior of CopperCube games. - Arrange the Process Explorer window and the game window side-by-side so that you can switch to the game window and simultaneously observe / monitor changes in CPU usage of the threads in the "Properties" window. - Switch to the game window and observe the changing CPU usage of the different threads - Check the last column in the "Threads" table ("Start Address"), see if the offending thread lies inside the main module (exe) or a DLL Example, on one of my systems (Windows 10, Nvidia GPU): - Setup: The "default scene", with the default cube & skybox. Default settings, Direct3D renderer, windowed mode ("dynamic/resizable"). - On my system, the main thread (exe module) of the CopperCube game was running with a CPU usage of ~20% - Additionally, there was one thread in the module "nvd3dumx.dll" with a CPU usage of ~1–2% (part of the Nvidia driver). - All other threads showed CPU usage close to zero |
||||
|
...and then I looked at the CPU usage of the CPU cores/threads on my system via Process Explorer. Your observation with ~100% CPU usage on one CPU thread appears to be the default behavior for CopperCube. I was tunnel visioning on process threads (software) instead of hardware threads (CPU). And I did not notice that one of my CPU cores was actually maxed out. Here is what I believe is happening: - The main-loop of the game appears to run the "wait-for-the-next-frame" logic as fast as possible, actively looping & checking for the precise moment to render the next frame instead of "sleeping". - This behavior only appears to change when the game-window loses focus, reducing the CPU usage of the game to nearly zero. Additional Info: My example legacy system (4-core/thread CPU): - Observed value: ~25% total CPU usage by the CopperCube process (summing the individual process-thread related CPU usage values from my previous post). - CopperCube pushes one core to ~90% – 100%. Your system (modern 24-thread CPU): - Theoretical value: ~4.17% total CPU usage by the CopperCube process. - CopperCube should still push one core to ~90% – 100%. Also tested my theory by setting the FPS-limit to "1". This resulted in a slideshow while still pushing a single core to 100% usage. For me, this confirms that the engine does not "sleep" between frames, but waits via active looping & checking, consuming maximum CPU resources on a single CPU thread (which is what can be observed) Tried OpenGL and DirectX mode, no difference. Regarding your observation that V-Sync has no effect: I can confirm this behavior on my system as well. While V-Sync may reduce the workload on the GPU (FPS-limit, monitor refresh rate, V-sync mode, and other factors affect it), CopperCube makes the CPU simply "burn" any saved cycles in its active waiting loop to guarantee minimal latency and a precisely timed update-cycle. Regarding your observation of lower CPU usage in fullscreen mode: The observed CPU usage may be misleading if the game was minimized or "not in focus", because CopperCube appears to "sleep" when the game window doesn't have focus. There may be other factors at play. For example, the tool used to measure CPU usage could be averaging values over time. OS-level or driver-level specifics could also affect the CPU usage, Process Explorer might provide more insight. Not 100% sure about some of these things. |
||||
|
To prevent confusion: In the context of the 2 posts above, "CopperCube" refers specifically to the standalone game exe. |
||||
|
More on V-sync (after additional tests): - Case A - FPS-limit/target >= refresh-rate: CPU usage appears to be significantly reduced (down to ~1 - 5% total CPU usage on my 4-core CPU). Seems to trigger wait-states as expected. - Case B - FPS-limit/target < refresh-rate: CPU usage stays high. Wait-states are not triggered, instead the active wait-loop is doing its thing. Minimal differences can trigger this behavior. A few more things: - Check if your global graphics settings don't force V-Sync to be OFF - Your monitor refresh-rate may be much higher than the default FPS-limit/target of 60 Try this if you want: - Enable V-sync for your game - Set the FPS-limit/target to be higher than your refresh-rate - Check if this leads to a lower CPU usage |
||||
|
Hey @Guest2 Thank you for detailed answer. It seems to me that it is an iGPU and dGPU combination issue, adrenaline driver more specifically. Even though it has a v-sync and it shows me 64 fps it actually runs on 400 somehow. |
||||
|
I don't think there’s anything wrong with your system. As long as you aren't experiencing stuttering, loud fan noise, high CPU or system temperatures, or extreme power consumption, I would simply accept this as the engine's normal behavior. A bit more on V-sync & refresh-rate: On many modern systems, the display refresh-rate is well above CopperCube's default FPS limit/target ("Wanted frames per second") of 60. G-Sync, FreeSync, and other modern features may also affect the CPU core load. Have you checked if your display is running at a high refresh-rate (144 hz, 240 hz)? Settings -> System -> Display -> Advanced display settings The CopperCube game-loop appears to "burn" CPU cycles to stay close to the target fps. It happens without V-sync. It happens if you enable V-sync and your refresh-rate is above the FPS-limit/target of 60. Three more ideas: 1) If you suspect that the rendering is unconstrained running at 400 fps, you could try to enforce an external fps limit via the AMD Adrenalin settings. But I'm not sure if this will actually help much. 2) Another thing you could try is forcing the use of either the iGPU or the dGPU to see if one or the other results in a lower CPU core load. It sounds like you’ve already experimented with switching between the two. 3) Setting process priority to lower than normal via task manager may also be a viable workaround. Commandline (use it in a batch-file) to enforce this on game launch: "start /belownormal game.exe" (remove quotes) |
||||
|
|
){kind=link}