A new ddrio implementation, ddrio-async, that wraps another ddrio implementation and drives it in a dedicated IO thread. This turned out to be a good solution to solve performance problems when running MAME with ddrio-p3io that is (currently) implemented with synchronous IO calls that are very costly: ~12 ms for a write over the ACIO protocol, ~4 ms for a read using an IOCTL. As this already adds up to nearly a full frame (60 fps) regarding latency, there isn't a lot of time left to do other stuff in a synchronous update loop. MAME's performance was unstable and dropped all the time below 100%. The result was a choppy gameplay experience.
Combining ddrio-async with ddrio-p3io, the combined backend is able to drive inputs/outputs at a rate of ~250hz = ~4 updates per frame. This results in an average input latency of ~4 ms which is as good as it can get with the p3io hardware's performance limitations that I measured (see the 4 ms for the IOCTL mentioned above).
This is more than good enough as as update frequency of the 573 hardware was slightly less than that (I got told something ~180 hz?).
tl;dr: Gameplay is great, smooth frame rate, IO feels amazing and responsive.
A new ddrio implementation, ddrio-async, that wraps another ddrio implementation and drives it in a dedicated IO thread. This turned out to be a good solution to solve performance problems when running MAME with ddrio-p3io that is (currently) implemented with synchronous IO calls that are very costly: ~12 ms for a write over the ACIO protocol, ~4 ms for a read using an IOCTL. As this already adds up to nearly a full frame (60 fps) regarding latency, there isn't a lot of time left to do other stuff in a synchronous update loop. MAME's performance was unstable and dropped all the time below 100%. The result was a choppy gameplay experience.
Combining ddrio-async with ddrio-p3io, the combined backend is able to drive inputs/outputs at a rate of ~250hz = ~4 updates per frame. This results in an average input latency of ~4 ms which is as good as it can get with the p3io hardware's performance limitations that I measured (see the 4 ms for the IOCTL mentioned above).
This is more than good enough as as update frequency of the 573 hardware was slightly less than that (I got told something ~180 hz?).
tl;dr: Gameplay is great, smooth frame rate, IO feels amazing and responsive.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
A new ddrio implementation, ddrio-async, that wraps another ddrio implementation and drives it in a dedicated IO thread. This turned out to be a good solution to solve performance problems when running MAME with ddrio-p3io that is (currently) implemented with synchronous IO calls that are very costly: ~12 ms for a write over the ACIO protocol, ~4 ms for a read using an IOCTL. As this already adds up to nearly a full frame (60 fps) regarding latency, there isn't a lot of time left to do other stuff in a synchronous update loop. MAME's performance was unstable and dropped all the time below 100%. The result was a choppy gameplay experience.
Combining ddrio-async with ddrio-p3io, the combined backend is able to drive inputs/outputs at a rate of ~250hz = ~4 updates per frame. This results in an average input latency of ~4 ms which is as good as it can get with the p3io hardware's performance limitations that I measured (see the 4 ms for the IOCTL mentioned above).
This is more than good enough as as update frequency of the 573 hardware was slightly less than that (I got told something ~180 hz?).
tl;dr: Gameplay is great, smooth frame rate, IO feels amazing and responsive.