synchronization-bug-fixes

AlexDorce commented

2026-05-24 23:21:26 +00:00

Owner

WARNING: The entire emulator is undergoing a pretty massive architecture shift in hopes of eventually offering some pretty hefty optimizations without losing the accuracy we already have. There is a lot of work to do before these optimizations can be brought in, it is a long term plan. As a result, the performance will be quite terrible in develop for a while until we can really put these future optimizations in motion.

That being said, this PR does a few things:

Fixes a bunch of savestate bugs
Introduces a new tree-like structure that can be used to inspect a savestate conveniently, both in C++ and through our python API. This feature is opt-in to avoid un-wanted heap allocations from a frontend perspective.
Ports the PPU and APU to the scheduler architecture. This fixes the syncronization problems we were facing though there are still some quirks.

Quirks of point 3 up above are as follows:

Although the PPU and APU do use the scheduler now, no significant effort has been made to refactor them to take advantage of such an architecture. We are currently scheduling every single cycle with the scheduler, which is why the performance is so bad right now. This will improve.
Not really a quirk, but this was necessary to get big_step to behave again. The scheduler makes it a million times easier to not botch the tickrate of each component when considering double speed mode.
I didn't port the timer because 1) it plays much nicer with the variable clockrate presented by double speed mode so it doesn't cause the same problems the other components do. This is also on the list for future improvements, but the timer also needs another large refactor before this can happen.

The long-term idea is to drastically reduce the number of synchronization steps required per-frame (I am planning to actually measure this as a metric), and try to "coerce" multiple repetative events into singular events that we can abuse SIMD to do quickly. If we do a good job at this, in a very-long term future state we can even consider introducing JIT without sacrificing accuracy.

WARNING: The entire emulator is undergoing a pretty massive architecture shift in hopes of eventually offering some pretty hefty optimizations without losing the accuracy we already have. There is a lot of work to do before these optimizations can be brought in, it is a long term plan. As a result, the performance will be quite terrible in develop for a while until we can really put these future optimizations in motion. That being said, this PR does a few things: 1. Fixes a bunch of savestate bugs 2. Introduces a new tree-like structure that can be used to inspect a savestate conveniently, both in C++ and through our python API. This feature is opt-in to avoid un-wanted heap allocations from a frontend perspective. 3. Ports the PPU and APU to the scheduler architecture. This fixes the syncronization problems we were facing though there are still some quirks. Quirks of point 3 up above are as follows: 1. Although the PPU and APU do use the scheduler now, no significant effort has been made to refactor them to take advantage of such an architecture. We are currently scheduling every single cycle with the scheduler, which is why the performance is so bad right now. This **will** improve. 2. Not really a quirk, but this was necessary to get `big_step` to behave again. The scheduler makes it a million times easier to not botch the tickrate of each component when considering double speed mode. 3. I didn't port the timer because 1) it plays much nicer with the variable clockrate presented by double speed mode so it doesn't cause the same problems the other components do. This is also on the list for future improvements, but the timer also needs another large refactor before this can happen. The long-term idea is to drastically reduce the number of synchronization steps required per-frame (I am planning to actually measure this as a metric), and try to "coerce" multiple repetative events into singular events that we can abuse SIMD to do quickly. If we do a good job at this, in a very-long term future state we can even consider introducing JIT without sacrificing accuracy.

AlexDorce added 10 commits

2026-05-24 23:21:26 +00:00