search

tonioni / WinUAE

WinUAE Amiga emulator
http://www.winuae.net/
552 stars 90 forks source link

cpu_thread option #265

Closed midwan closed 10 months ago

midwan commented 11 months ago

Hi Toni,

I noticed that the cpu_thread option (named cpu_threaded in the config file), causes the emulation to show a black screen if enabled. Since this is not visible in the GUI, I was wondering if that's something you're aware of or not? The emulator still seems to work, CPU usage seems spread to a separate core, and I can return to the GUI, but the screen doesn't draw any lines.

It would be nice to be able to use this option properly, especially since after the emulation rewrite things seem to have slowed down (up to 3 times higher CPU usage for the same scenarios, from my tests). Being able to offload the CPU emulation on a separate thread, might help improve the performance, especially on slower systems.

tonioni commented 11 months ago

It is experimental option that never got anywhere. I can try to fix it someday.. And it won't help with compatible modes anywhere where CPU must be slowed down by chipset. Normal (non-CE) modes should not be noticeably slower. (If they are, something is wrong).

midwan commented 11 months ago

@tonioni Thanks for the clarification. It's expected that in cases where we need CE modes, this won't help, of course. But it might help in other scenarios (e.g. fastest possible CPU emulation/JIT/Non-CE modes).

I'll keep an eye out for any fix in the future then, and leave it for now.

Regarding the performance difference I mentioned, it seems to be in the custom/drawing/blitter combo, not the CPU emulation. The newer code for these (after the recent rewrite to improve accuracy) seems to be slower, at least noticeably so on slower devices.

To give you a concrete example: Game: Jim Power's title screen, Hardware: Pi400 (overclocked at 2.2GHz) Config: Quickstart A1200 (the A500 is less demanding, so I use the A1200 to stress things more)

Using the older (pre-rewrite) code, this runs at full 50 FPS. CPU usage is about 80% Using the newer rewrite, it maxes out a CPU core at 100% and only manages to hit 40 FPS.

It works fine on a more powerfull RPI5, and x86_64 platforms don't notice the difference either, of course.