Emulationstation 100% Single Thread Usage

theofficialgman

@pjft To clarify, the switch in this case should act just like the jetson nano/tx1 development kits or any hardware based off of them.

There is unofficial support for them in retropie (at my request a few months ago) and we have many users in the switch modding community who use retropie on their switch and jetson nano devices as well.

The power settings have no affect on this issue. My reference test x86_64 system (its an intel core 2 duo with its igpu) is of similar single core performance to the tegra-x1 (both around 300 geekbench5) and it idles at about 1-2% single thread usage for emulationstation. So its not that the tegra is not powerful enough.

What I would be interested in would be other users reporting back on their experience on other arm64 systems running 64bit kernels.
Other nvidia gpu's (of the maxwell generation as this tx1 is) would be interesting as well.

Does emulationstation have the capability to run under software rendering since that would be interesting to test as well?

mitu

@gmesmer said in Emulationstation 100% Single Thread Usage:

What I would be interested in would be other users reporting back on their experience on other arm64 systems running 64bit kernels.

There is arm64 support for the Pi4, in testing, but I don't remember this kind of behavior with EmulationStation to be reported. Have run it a few times while testing and I didn't notice this behavior.

Does emulationstation have the capability to run under software rendering since that would be interesting to test as well?

Not explicitly - though I managed to forcibly run it under Mesa's SW driver and the difference was noticeable. Does Nvidia's driver implements software GL ?
Do other OpenGL application work fine ? Try running some of the SDL2's tests (testgl2, testgles2) and see the if the CPU usage is similar.

theofficialgman

@mitu GL applications all run great, (many benchmarks, emulators, other applications tested which use varying versions of opengl) no issues with 100% thread usage. Of course some GL benchmarks will be cpu bottlenecked when run but thats not what is happening here. As I said previously, manually disabling vsync in emulationstations settings I am able to reach over 200fps with no change in cpu thread usage.

theofficialgman

also just for more info, note that even with the blank screensaver active I still get near 100% thread usage

theofficialgman

maybe this has to do with audio not working for me within emulation station? The default audio card and master audio device correctly change audio volume but I don't hear any navigation sounds (they are on). before anyone asks, yes audio is working in retroarch and everything else. I've tried manually setting emulationstation to pulse and the Master audio device as well as many other things to no avail
edit: ignore what I have crossed out, I wasn't aware that my theme could affect the audio and my theme has the scroll sound commented out for some reason

pjft

@gmesmer I don't know about the audio, but I was going to report the same experience as @mitu regarding Raspberry OS 64 tests. From the little I recall testing it out back in the day, I don't recall the 100% CPU usage.
If you run ES with the debug flag, is there anything interesting in the logs that keeps getting repeated - perhaps suggestion what's keeping the CPU at max usage?

theofficialgman

@pjft no, nothing in the debug besides expected button input logs

theofficialgman

alright new development
running in forced windowed mode the cpu usage goes down to below 5% (framerate is still a solid 60fps)

theofficialgman

I built emulationstation manually with the GL 1.4 backend to see if there would be any difference and I have the same issue with it.

maybe this very old stackoverflow post still applies here? https://stackoverflow.com/questions/21925313/100-cpu-utilization-when-using-vsync-opengl

theofficialgman

@pjft @mitu I found a solution which works well enough in this case
this seems to be a configuration set deliberately with nvidia linux drivers to busywait on vsync

setting this flag changes that behavior __GL_YIELD=USLEEP
cpu usage goes down to 30% (not as good as windowed mode) and the frequency drops significantly as well (settles in around 600mhz)
overall I think this is good enough

pjft

@gmesmer Interesting. Thanks for sharing - it might be helpful for others who try to set it up in this context.

mitu

@gmesmer are you running in windowed mode as fullscreen/borderless ? You might want to try it to see if it yields the same CPU usage.

setting this flag changes that behavior __GL_YIELD=USLEEP

You should test to see how that affects emulation, it might introduce some latency.

theofficialgman

@mitu emulation is unaffected by __GL_YIELD=USLEEP

as for fullscreen/borderless, I've tried both exclusive fullscreen and borderless fullscreen but it seems that the nvidia driver recognizes that only one thing is on display so effectively the borderless is treated as fullscreen.

Full windowed mode (ie: not borderless fullscreen) goes through the compositor and has different results

anyway, I did my research on this, the default settings is to busywait on vsync for most nvidia drivers which pins the cpu to 100% on that core

theofficialgman

also my apologies for the slow replies. even though I think my email notification settings are correct. I have never once gotten an email from this forum