Fullscreen vs Windowed CPU usage

I’m not noticing any frame drops, the scrolling is smooth also, but I noticed the CPU usage in windowed mode is basically the same as my idled PC and when in full screen it goes as high as 30%, surely it differs from core to core, the only ones I tested were FBA NEO and GenesisPlus GX with the same results in both GlCore and GL. Since I couldn’t figure out how to capture the CPU stats overlay in full screen, I took it as fast as I could as soon as I exited full screen, the second capture shows how much CPU it uses in windowed mode. I’m sure it affects heavier cores, so I’d like to know what is causing these peaks. Interesting when I activate fast forward in full screen the CPU usage drops below 10% and I see the GPU around 3 to 4%. Note that in this case I capped the fast forward to 3X.

I'm on Windows 10 1903
I7 2600 3.8GHZ
GTX1660ti 6GB
Retroarch 1.8.2 (late December build)

Can anyone try to replicate this and see if RA uses much more CPU in full screen?

In windowed, DWM takes over the sync, adding latency and (possibly?) messing with things like hard GPU sync. I would assume that’s at the root of the difference.

I had Sync to 1, then I set it to 3 to see if there’s difference in full screen. I added runahead instances up to 6 and it dropped from 25~ to 20-18%, the game input response was amazingly fast, almost as it reacted before I actually did the commands. But, with Hard Sync and Runahead to their max, shouldn’t it increase the CPU load instead of actually dropping it? I read on other posts that standalone emulators usually perform faster than in Retroarch, I always took that with a grain of salt, so when seeing these CPU peaks I’m trying to figure out if that 30% CPU load in a simple 2D game is really the expected behavior.

Edit: I now turned off both Hard Sync and Runahead, even before loading any content Retroarch is eating up 25-26% CPU, I think it didn’t happen some time ago, how can I trace the culprit?

No core, nor any content loaded, how is it eating that much CPU without processing stuff?

Yeah, that’s not really true in a general sense. There are some things that would cause it, like non-PIC-compliant dynarecs (see: desmume) that don’t work when the core is a dynamic library and/or GL threading stuff like in PPSSPP, but RetroArch is usually as or more efficient as any standalone interface.

I would suggest hooking up to a debugger and see where all the function calls are coming from that are pushing up your CPU load.

I would suggest hooking up to a debugger and see where all the function calls are coming from that are pushing up your CPU load

How to do it?

some instructions for using gdb for it are here:

instructions for MSVC are here:

1 Like

Here’s what I did. I downloaded the latest nightly and started it, in order to get the CPU usage without interference from another application I recorded it from my smartphone. You’ll notice that without any logic, some settings are stealing lots of CPU cycles, like changing the Monochrome icons to FlatUI and back, how come?

Sooo I wanted to post a link but my posting privileges are… weird


So, 5 years and the issue persists. I’ve played with some settings in the Nvidia panel, threaded optimization ON/OFF, etc. I noticed that turning off V-Sync helps a bit but with it off, it’s not ideal. Edit: Actually, turning threaded video and vsync together makes the 25~30% load drop to 15~20%. It’s still heavy for an idle application.

Edit: With more tests, I switched to the 3 available GL related drivers and all of them eat up 30~35% CPU, while Vulkan drops to 15%, Direct3D drivers in the same range as Vulkan, but still, CPU is processing a ghost. Since it’s a Nvidia driver issue, what to expect, is it something that can be looked after and fixed?

1 Like

Apparently many people have been complaining for years and every time the same answer comes back, the driver is essentially spin-waiting. https://stackoverflow.com/questions/21925313/100-cpu-utilization-when-using-vsync-opengl

As I recall, Nvidia juggles the draw calls in the drivers to fill the shader queues whereas AMD and Intel just follow the draw call specification. This has been a boon to Nvidia in DX11 where draw issues are not optimal but has been a disaster on DX12 where the spec does not like this type of rearrangement and needs to allow more low level hardware access. It’s probably the same on the OpenGL side vs Vulkan.

And also

Nvidia’s driver is using spinlocking to wait for the next VSync in OpenGL. This causes 100% CPU usage on one (or multiple - with “threaded optimization”) cores. To prevent this you should ideally do your own syncing or at least sleep the render thread until there’s less than 1-2 milliseconds till the next VSync.


Edit: @aorin1 I’m curious ,can you do your test with the settings below and threaded optimization on again ? (nvidia profile inspector)


It totally nailed the issue. My CPU load is now 0~1% even in game. I tested scrolling with the 240pSuite and a game, the CPU only increased 1 or 2% more when I activated fast forward. I’m not sure if something can be done on the Retroarch side, or this is isolated on the Nvidia driver. The difference is huge, it was eating almost 40% of the CPU and now it’s gone.

For reference on the performance load, without any latency used, the CPU load was 30~36%, now with the @ProfessorBraun settings in the Nvidia driver, even with 12X, runahead is eating 11~13% of the CPU, now that’s optimization.

Edit: I forgot checking the video driver, and I noticed I forgot it in Vulkan, so coming back to any GL driver, the CPU load is still high, almost 30%, I’m using Vulkan for now.

More tests: I started RA without any previous config, a clean installation, I started customizing menus I don’t use and setting a wallpaper, so I could see what kind of config could affect the CPU load in GL/GLCore. Suddenly, from 1~2%, the CPU load went up to 10~12%, if I switch to Vulkan, it drops to 0~1% like it should. I believe it’s not isolated on my end, others may notice this if they look for it.

1 Like