PR #3351 (Don't delay speaker data) introduced (yet another) performance regression
e.g.
DKCR Title Screen
--------------------
4.0-8388 = 101 FPS
4.0-8390 = 93 FPS
The settings used for testing are in the attachment below:
It actually goes quite a bit faster for me because audio is being sent correctly. I go from 92fps in 4.0-8388 to 99 fps in 4.0-8390.
(12-22-2015, 06:48 AM)JMC47 Wrote: [ -> ]It actually goes quite a bit faster for me. I go from 92fps in 4.0-8388 to 99 fps in 4.0-8390.
Test it in portable mode with only a pad or keyboard as input device. Use the .ini files from the first post (see attachment).
NOTE: The IR in the dx11.ini file is set to 6x (EFBScale = 9). Change it to 1x (EFBScale = 2).
Why would I use those settings, the change is for Wiimote audio? The only setting you should be messing with when testing it is "Enable Speaker Data"
If you still get a regression with speaker data disabled, then it's likely a problem on your end as the new code is disabled in that case.
Fixed (!) in 4.0-8396
This is the second time a sourcecode cleanup by "lioncash" fixes a weird performance regression.
The changes in 4.0-8396 can't affect performance, with an exception for possibly having a very tiny difference when launching a game. It sounds more like you didn't have a consistent performance problem to begin with.
Jos is right, it likely wasn't my DiscIO refactor that solved it.
It wouldn't be the first time kirbypuff find "regressions" that makes no sense and that nobody can reproduce either...
If that commit has nothing to do with the perf. regression, then it's probably one of these things:
- Sometimes the precompiled Windows builds aren't synced with the changes/PRs shown in the changelog (this happened before). This means the previous commit (or the one before it) fixed the issue.
or (most likely):
- A change/bugfix in the compiler options and/or build script of the PC that spits out the automated Windows-x64 builds. Something was wrong that affected performance (on certain CPUs), but got spotted and fixed in the meantime.
Even the contents of the Windows package changes from time to time. Sometimes extra junk is bundled with the Win-x64 builds, like the VC2013 .DLLs (despite Dolphin using VC2015u1) and .qt config files in the WxWidgets builds.
P.S. Lucky Seven (777 posts) FTW
(01-02-2016, 03:02 AM)kirbypuff Wrote: [ -> ]- Sometimes the precompiled Windows builds aren't synced with the changes/PRs shown in the changelog (this happened before). This means the previous commit (or the one before it) fixed the issue.
Those two commits shouldn't fix any performance regressions either. Also, when has builds desyncing happened before? I've seen builds being missing for certain operating systems sometimes, but that would be very obvious to notice on the download page.
(01-02-2016, 03:02 AM)kirbypuff Wrote: [ -> ]- A change/bugfix in the compiler options and/or build script of the PC that spits out the automated Windows-x64 builds. Something was wrong that affected performance (on certain CPUs), but got spotted and fixed in the meantime.
I doubt it. It sounds less impossible than your other suggestions, though.
(01-02-2016, 03:02 AM)kirbypuff Wrote: [ -> ]Even the contents of the Windows package changes from time to time. Sometimes extra junk is bundled with the Win-x64 builds, like the VC2013 .DLLs (despite Dolphin using VC2015u1) and .qt config files in the WxWidgets builds.
Okay, but extra junk doesn't affect the performance. The exception is if that extra junk is old game INIs that enable unnecessary options, but I know we haven't had any of those in the Windows builds for a few months, and they certainly wouldn't be added by 4.0-8390.