Current releases and nightlies run slowly on 3DS.

[FateForWindows]

Description

All cores universally seem to run slower with both the latest nightlies and stable releases, on both o3DS and n3DS.

Expected behavior

Most cores (such as Picodrive, Genesis Plus GX or SNES9X 2005 Plus) run at full speed on N3DS.

Actual behavior

Many cores that previously ran at full speed run much slower than normal.

Steps to reproduce the bug

1. Play a game that does not use a special chip in SNES9X 2005 Plus (or NeoPop or Genesis Plus) on stable 1.6.0.
2. Install the latest nightly.
3. Test the same core and game again.

Bisect Results

This began happening sometime in between releases 1.6.0 and 1.6.3.

Version/Commit

You can find this information under Information/System Information

• RetroArch: 1.6.3.

Environment information

• OS: 3DS system software.

[meepingsnesroms]

What is this, there is no description or title?

[FateForWindows]

Uh wut? I didn't even remember posting this, I remembered posting another issue.

People have been reporting that the latest version of Retroarch runs much slower on 3ds, and this doesn't seem to be related to any cores. It's happening with all cores in general.

[inactive123]

Can you do a bisect? Nothing else is really going to help I am afraid. We no longer have any active 3DS developers, so we would need somebody bisecting this and telling us with certainty what caused this.

[FateForWindows]

I will try to do this later. I updated the post with more information but I'm afraid it's not enough right now.

[danieljg]

I ran a bisect on this, it seems the performance issue has something to do with the 'build fix for platforms without threads' (merged in b64fe2a).

In my testing, the loss in performance is quite real. Tetris Attack's title screen goes from fullspeed to ~45 fps in the recent 'slow' builds using snes9x2005 'plus' (meaning with the blargg apu turned on).

[inactive123]

So if you go back one commit before that commit, you get the lost fps back?

@fr500 You might want to be involved in this discussion.

[danieljg]

This is the first time I've bisected w/git, so I'm repeating the procedure just to make sure. It's not excessively time consuming so I should be back rather soon.

[inactive123]

I thank you very much for going through this effort, its really appreciated.

[danieljg]

I'm sorry to say my original bisect took a wrong turn somewhere (I must have forgot to reinstall the program on the cia in one iteration or something). The commit which I pointed out a couple of messages ago was wrong.

I have now verified that the offending change is contained in one of the following two commits:
c101b4c
c288216

I haven't been able to determine more than this since commit c101b4c doesn't compile, the build process throws a message saying some warnings are treated as errors (implicit declaration of function, etc).

Here's the tail of my bisect log:
# good: [d889f594a3e86383798cf81d5b145ca290390361] small fixes
git bisect good d889f594a3e86383798cf81d5b145ca290390361
# only skipped commits left to test
# possible first bad commit: [c2882164f9a1f1d68dc06a80df9bdee716b0c520] reenable rewind if the user disables netplay
# possible first bad commit: [c101b4ccb3e767111c23c2d6495dcb1adef01d7e] netplay tweaks: disable rewind
# bad: [c2882164f9a1f1d68dc06a80df9bdee716b0c520] reenable rewind if the user disables netplay git bisect bad c2882164f9a1f1d68dc06a80df9bdee716b0c520
# only skipped commits left to test
# possible first bad commit: [c2882164f9a1f1d68dc06a80df9bdee716b0c520] reenable rewind if the user disables netplay
# possible first bad commit: [c101b4ccb3e767111c23c2d6495dcb1adef01d7e] netplay tweaks: disable rewind

Please let me know if there's anything else I can do. I'm pretty sure I narrowed it down properly this time around.

[danieljg]

Ok, I figured it out. There's a bug in commit c288216. An if statement was wrapped around an ifdef directive wrongly, which was easy to miss since it only affects systems with no network support.

I wrote the fix for this and thought of sumitting a pull request, but it seems to have been piled into the existing reqest I had regarding 'am/pm' style times for some reason...

The relevant fix is commit a87fc9c which can be seen in PR #5235.

[inactive123]

OK, I just backported your commit -

921418a

Tell me if this fixes the performance of RetroArch on 3DS.

If it does, I might have to push a new stable version soon.

[danieljg]

@twinaphex Yes, this fixes the performance issue on the 3ds port. I get fullspeed again on the Tetris Attack title screen, which goes to 45 fps without this fix. It should also fix performance in some other platforms, such as the wii and psp ports, essentially any port without network support. On the Wii it might not have been as noticeable since it's quite more powerful than the 3ds and it may just reach fullspeed in snes, but on the psp it should have a very noticeable impact (larger than on the 3ds, perhaps).

[stoz]

Just came here to report some testing I did. I haven't used my 3DS for emulation for a couple of months but decided to try it out again on the weekend. I updated to 1.6.4 and Gambatte was not able to run some Game Boy Color games at full speed (got around 45fps) which I found surprising.

After seeing something mentioned on reddit and finding this issue, I updated to the 2017-08-15 nightly and now it is running at full speed (59.whatever fps)

[FateForWindows]

I wasn't actually the first one to discover it, there were already a few pages on GBATemp's Retroarch 3DS thread talking about issues, I was just the first one to submit this issue on github.

Well, since it's fixed, I might as well close this.

[roflcopter777]

Currently using 1.6.7 as well, going to test and compare my results to that and a nightly build on my N2DS XL, which for the record, uses the same 804 MHz CPU.

[roflcopter777]

Captured the performance issues on my camera:
Used both 1.6.7 main and 9/19/17 nightly build

Video link of 1.6.7 regular:
https://www.dropbox.com/s/h1cfchavi0dosxo/DSCN9580.MOV?dl=0

And

Video of 1.6.7 9/19/17 nightly:
https://www.dropbox.com/s/d7f3u7fieq0sta0/DSCN9581.MOV?dl=0

[inactive123]

I think honestly what you might be running into is that maybe changes to the SNES9x cores made the core slower for 3DS. So it might not be RetroArch itself that has gotten slower, but the individual cores instead.

[ghost]

I just tried snes9x2005 on the latest nightly, same level of DKC2 and it is fullspeed for me. Will post a video.

[roflcopter777]

@bparker06 Seriously? Are you using Snes9x 2005 or Snes9x 2005 PLUS? Because Plus is the one I'm using due to it having Blargg's S-SMP core (the inaccurate audio bothers me). The difference is Plus has superior audio emulation. Snes9x 2010 is completely unusable on N3DS. Well then. To me, it sounds as if Snes9x 2005 should be used over Plus at the cost of worse audio.

@twinaphex So what do we do in the mean time? Sounds like this needs to be closed since nothing can be done. Not trying to be negative, but it sounds like the issue will be very difficult to be tracked down and resolved. Would @qwertmodo know?

[ghost]

non-Plus here.

[roflcopter777]

@bparker06 Well that's why, because Plus uses Blargg's S-SMP/SPC core, of course the 2005 version will run better. 1.52 audio is too much for N3DS. I wouldn't even know where to look in Snes9x libretro to see what regression there was, if any. >.>

Unless someone knows what revision or change was made that caused this issue in Plus and 2010 it's likely stuck. Again, being realistic, not negative, because it's evident something broke somewhere. Where would one even begin?

[roflcopter777]

Well, guess my work is done here. I knew those videos would be in vain.

[ghost]

Just tried Plus and indeed it has the same slowdown as your video.

[roflcopter777]

Okay, so that's two for two, where do we go from here? I was looking at the repositories for Snes9x 2005 and 2010, and I don't see any red flags per se, I tried looking for the libretro Snes9x mainline, but I didn't see anything odd in there either. Is this something that can't be changed or fixed, heck, or even checking out the regressions? I don't know what else to do. Surely, the N3DS can handle 1.52 audio. If the Wii can, which is pretty weak, so can the N3DS.

[ghost]

I just tried the 2005 Plus core that was bundled with 1.6.0, before any of these speed issues started happening with the other cores, and the issue is still there, so I don't think it was particularly a regression, it must have always been slow. Turning on fast-forward gives me an extra ~8fps or so, which I'm assuming means that there is indeed a CPU bottleneck. Whether this can be optimized or not I guess is a different story.

[roflcopter777]

Damn, I was afraid of that. I was going to try incremental versions, 1.5.0, 1.3.3, etc and roll back until I found one that worked. See, I would use Snes9x 3DS, if it had Blargg's sound core, because as it, it runs very well, maybe the N3DS is just incapable of running a superior audio core. I don't expect perfect Snes emulation, no, but if that sound can be just a tad improved, it would be perfect in my eyes. So much for the 804 MHz CPU. Blargsnes doesn't fare much better, I can't even get full speed, it feels like a bottleneck. I dare not ask @twinaphex any further questions, for obvious reasons. Is the N3DS is too weak for better SPC700 emulation, even with the four times processing power?

Edit: I'll try other versions as well, like 1.5.0, 1.3.3, etc to see what I get. Using DKC2 as a benchmark.

[roflcopter777]

@fr500 Any insight?

[roflcopter777]

You did watch the videos though, right? Even non-special chip games suffer and drop to 41-45 fps in some cases; the N3DS simply isn't powerful enough for accurate SPC700 emulation. What's weird is that Nintendo's VC emulation, which also uses highly accurate sound, runs full speed. So clearly the hardware is capable somewhere.

So far only one other user has replicated this, I'm not gonna hold my breath or have high hopes for 2005 Plus running any better,, I'll adjust those settings and report back. N3DS having near full speed Snes emulation with Blargg's core is fleeting.

Edit: Audio latency is set to 160 ms, the other options I haven't tested yet. Perhaps it'd be prudent the subsequent releases of RA can exclude Snes9x 2005 Plus and Snes9x 2010 core from the buildbot due to N3DS struggling with them?

[roflcopter777]

@fr500 Here's the results of my testing your suggestions,

Core used:
Snes9x 2005 Plus (Snes9x 1.43 with 1.52 audio)

N3DS info:
System version: 11.5
CFW: Luma 3DS
Method of app: CIA installation

Settings I changed:
Changed audio resample from sinc to CC
Changed audio driver to CSND
Changed sync audio to "off"
Changed audio latency to 200 ms (overkill, but for the sake of it)

Games tested:
Final Fantasy VI runs at 51 fps during the opening scene
Donkey Kong Country 2 runs at 48 fps on the second level in first world
Aladdin ran at full speed during the first level
Chrono Trigger ran at 52-55 fps during the opening scene

This is rather confusing, because, in my opinion, this accentuates the fact the N3DS was simply never meant to being able to run Blargg's S-SMP audio core, performance is affected to adversely. On the other hand, the games that do run via Snes VC injection, run almost perfectly (60 fps, highly accurate audio). Downside is there's only support for the Cx4 and DSP1 co-processors.

Conclusion:
I propose that Snes9x 2005 Plus and Snes9x 2010 be removed from the repository/build bot.
I see the reason due to Snes emulation having current issues in performance in conjunction with 1.52 code. So yes, I'm conflicted, it can run well via official emulators.

I'm at a loss, if more optimizing can be done, great. But I can't make that judgment, and I can't suggest that the Blargg S-SMP cores be removed, but I personally don't see any other option. Where do we go from here? Maybe there's a bottleneck or the CPU is being throttled when loaded as a CIA app, but not as a 3DSX app.

[FateForWindows]

Why would this need to be removed if pcsx-rearmed doesn't run at full speed in most games and mednafen VB runs at unplayable framerates, yet they're still there?

[roflcopter777]

@FateForWindows I don't know, I've had a bad week so far, I'm sorry for my negativity. I may need to start a bountysource to rally support to add Anomie's S-SMP to Snes9x since Blargg's S-SMP is a bottleneck for the N3DS CPU. I just wanted to see Snes emulation close to Nintendo's official Snes VC, I was too ambitious, and I'm sorry for suggesting to you to add 1.52 audio (on GBA Temp) to your fork of Snes9x, it was rude and inconsiderate. Not to mention it would kill performance.

[FateForWindows]

Don't worry, I'm having a bad week as well. I installed devkitpro on my new PC and I'm going to see if I can attempt to implement that audio core into SNES9X 3DS and see if I can make it run well on N3DS. I probably won't add it to the official repository since the emulator is mostly intended for O3DS.

[roflcopter777]

So it'd be like an N3DS branch/fork of some kind? I tried BlargSnes too, for the record, but I couldn't get full speed on that, maybe it doesn't like N3DS hardware. No worries though. Take your time, if you want me to help test it, I can.

What I'm considering doing is starting a bounty, but I'm still on the fence.

[revvv]

Looks like that 3DS is slow again. I tried cap32 and crocods. (Both Amstrad CPC emulators)
I tried to compile the old version 1.6.6, but I don't know how to downgrade to libctru 1.x.
If you have an idea how to fix the current version I'm willing to compile/test.

Or does anyone know where to get the old version 1.6.6? I know this has been asked a thousand times, but I never saw an answer if there is a build archive or why there is none.

[LibretroAdmin]

Issue is too old and has been closed. Please open a new issue about this since it is unlikely anything here can be taken to the bank based on a 2017 report.