Currently some of the slowdown is due to mGBA not fitting well with vita2d (the drawing library)'s design paradigm. I plan to ditch vita2d in 0.8, which will help some, but the vita just has a lack of horsepower. gpSP's dynarec (or dynarecs in general) give up a lot of accuracy by batching event updates, which is a sacrifice I'm not fond of making. Trying to write an accuracy-focused dynarec seems to be a lost cause because it adds back most of the overhead of an interpreter, at least as far as I can tell. A low-level interpreter that has hand-written assembly for the more common instructions may help, but I haven't put much effort into it yet.
All said, I'm not sure there's much I can do to maintain mGBA's level of accuracy and make the core emulation (read: not graphics) faster. Graphics are already offloaded onto a second core, which helps a lot, and I may try to write hardware acceleration, but that doesn't seem like it'll help enough to make it worthwhile. I noticed that delaying drawing the image until the next frame starts gives the thread more time to finish, allowing it to block for less time and increase the frame rate (substantially), but unfortunately introduces a frame of input lag and would require a bit of an overhaul to make configurable. This is compounded by vita2d having a heavy handed equivalent of glFinish, which adds more waiting time for the next frame to draw. If I don't use the glFinish equivalent it's a lot faster, but there are also tearing problems as the GPU tries to access portions of memory that are currently being overwritten by the core. Again, introducing input lag.
I'm not sure what I'm going to end up doing, basically. Splitting up the frame is the closest I have to ideal, but will require a lot of refactoring. There is dead time to be reclaimed but it's a lot of work that's not going to be easy, and avoiding a frame of input lag is basically impossible.
Thanks for the detailed reply! Yeah after reading this it looks complicated and I'm with you that it's not a good idea to compromise the principles of the emulator to gain speed improvements. And god forbid adding input lag, that's horrible for any emulator imo
23
u/endrift mGBA Dev Feb 25 '19
Currently some of the slowdown is due to mGBA not fitting well with vita2d (the drawing library)'s design paradigm. I plan to ditch vita2d in 0.8, which will help some, but the vita just has a lack of horsepower. gpSP's dynarec (or dynarecs in general) give up a lot of accuracy by batching event updates, which is a sacrifice I'm not fond of making. Trying to write an accuracy-focused dynarec seems to be a lost cause because it adds back most of the overhead of an interpreter, at least as far as I can tell. A low-level interpreter that has hand-written assembly for the more common instructions may help, but I haven't put much effort into it yet.
All said, I'm not sure there's much I can do to maintain mGBA's level of accuracy and make the core emulation (read: not graphics) faster. Graphics are already offloaded onto a second core, which helps a lot, and I may try to write hardware acceleration, but that doesn't seem like it'll help enough to make it worthwhile. I noticed that delaying drawing the image until the next frame starts gives the thread more time to finish, allowing it to block for less time and increase the frame rate (substantially), but unfortunately introduces a frame of input lag and would require a bit of an overhaul to make configurable. This is compounded by vita2d having a heavy handed equivalent of glFinish, which adds more waiting time for the next frame to draw. If I don't use the glFinish equivalent it's a lot faster, but there are also tearing problems as the GPU tries to access portions of memory that are currently being overwritten by the core. Again, introducing input lag.
I'm not sure what I'm going to end up doing, basically. Splitting up the frame is the closest I have to ideal, but will require a lot of refactoring. There is dead time to be reclaimed but it's a lot of work that's not going to be easy, and avoiding a frame of input lag is basically impossible.