Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve performance #5

Open
gregtour opened this issue Jul 7, 2015 · 5 comments
Open

Improve performance #5

gregtour opened this issue Jul 7, 2015 · 5 comments

Comments

@gregtour
Copy link
Owner

gregtour commented Jul 7, 2015

No description provided.

@gregtour
Copy link
Owner Author

Initial performance on my PC yielded ~4600 FPS before changes. After simple improvements, this jumped up to 6000 FPS.

These numbers may be very much platform specific.

The basic changes were to avoid trivial function calls, pull certain sections with redundant conditionals out of the CPU emulation body through goto's (gb_halt code), and to create an innermost loop that calculates the number of instructions before an interrupt will occur.

Future improvements might be more difficult. One change could be creating a separate READ command for ROM reads with specific addresses (i.e. instructions) upon a closer look. Other places for improvement include pre-calculating values like address banks, using memcpy for DMA, and anything else.

The target is a 10,000 FPS emulator, which should be possible. The theoretical best performance would be in the range of 60,000 frames per second when comparing the system clockrates, and potentially more when using advanced processing features, multiprocessing, and other tricks.

@deltabeard
Copy link
Contributor

VBA-M uses 2% CPU on my computer with sound on. This project (performance branch) uses 14% with sound off on Windows 8.1.

@gregtour
Copy link
Owner Author

Hm, fair point. When you started talking about performance I figured that meant in terms of maximum frame rate, so that's what this is optimized for. There are no delays or thread sleeps, everything is kept in a busy loop. So yes, it uses a high percentage of CPU time. It would make sense for the normal speeds (Normal, Fast, Faster) to have a sleep somewhere. I'm guessing it should only use about 1% then. Currently, I'm getting around 6,000 frames per second on the performance build with one core. With a little bit of threading the number might be able to go up. There's not a whole lot of purpose to building the fastest GameBoy emulator around, but it might be an interesting challenge.

Any platform that this can be built for is probably already sufficient to run at full framerate. However, if the target platform were archaic enough, there might be a need to use more innovative techniques to get a game running. That's really beyond me.

Also, I would say adding sound support would make no difference to performance.

@deltabeard
Copy link
Contributor

My own goal with this project is to get the CPU usage down as low as possible whilst still maintaining 60fps. :)

@gregtour
Copy link
Owner Author

gregtour commented Sep 6, 2015

So I tested the emulator on the Raspberry Pi (first generation) and I noticed that on some games the frame rate was only half the necessary 60-61 fps. However, when I turned full frameskip on, that number climbed back up to 240 frames per second. This leads me to believe that in general the emulator is GPU bound and that some optimizations to the framebuffer and rendering could be really useful.

CPU optimizations might still be useful for targets with less processing power than the Raspberry Pi B.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants