Dolphin, the GameCube and Wii emulator - Forums

Full Version: Another performance regression (4.0-5319 and newer) [FIXED!?]
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5
Starting with 4.0-5319, Dolphin took a serious performance hit - up to 25% slower (with both backends, EFB2RAM and EFB2Tex):

nsmb cake intro:
-----------------------
74fps -> 56fps (D3D, EFB2RAM @ 1xIR)
60fps -> 47fps (D3D, EFB2RAM @ 6xIR)
60fps -> 45fps (OGL, EFB2RAM @ 6xIR)
95fps -> 72fps (D3D, EFB2Tex @ 6xIR)

This is the dev. build and PR / commit which caused the regression:

4.0-5319:
PostProcessing: Add support for user-supplied anaglyph shaders. (PR #1817)

The previous build (4.0-5315) doesn't have this problem.

-----------------------
Testing needed !
-----------------------
* Use the config files below (see attachment) in portable mode <-- see the section "for advanced users only"
* Run the the nsmb cake intro with builds 4.0-5315 and 4.0-5319 and compare the frame rate.


It would be great if any of these users (listed below based on their hardware specs) could perform a regression test :

* cammelspit
* Echoes
* ExtremeDude2
* GeneralFailer
* kinkin ?
* Nfaug
* omega_rugal
* slarlac249
* Stevoisiak
* sulblazer
* Tino ?
Did you add this to the issue list?

https://code.google.com/p/dolphin-emu/issues/list
Sounds like D3D EFB -> Ram is on par with OGL performance. Did you test against OGL to see if that's the case? Probably some issue or inaccurate code in the D3D backend was speeding up emulation while causing other issues. I keep wondering if EFB -> Ram and CPU -> EFB access etc.. can be optimized without breaking anything, performance hit is just too large with some games.
Yeah the case here might be D3D was bugged with EFB -> Ram or OGL is too slow. The former is likely the case sadly.

It's like ZTP Hyrule Field. I went from having 20fps to 25fps without the speedhack with D3D. OGL was dog slow at around 12fps to 16fps. Then OGL become just as fast as D3D and now I think with both I get a measly 12fps to 16fps without the speedhack.

Hopefully devs will acknowledge an issue if there is one.
Unable toe reproduce doing an every 100 build check on D3D. No noticeable spike down past the builds you reported. It's possible that adding in that option caused some kind of problem though, I will notify Armada.
The regression is easy to reproduce: just run the the nsmb cake intro with builds 4.0-5315 and 4.0-5319 and compare the frame rate.
Again, I'll let Armada know, but I'm not seeing a large enough difference to draw a conclusion yet. Seems like a merge that shouldn't affect performance at all, though, so it's possible something is going wrong.
Update #1:
-----------------
The OpenGL backend has the same issue (even worse): 25% slower compared to the previous build.

60 fps -> 45 fps (@ 6xIR)


Update #2:
-----------------
It's not just EFB to RAM... EFB to Texture is affected as well:

95 fps -> 72 fps (6xIR, D3D)


Update #3:
------------------
Same thing at 1xIR:

74 fps -> 56 fps (1xIR, D3D)


Update #4:
-----------------
POVRay bench (3 runs x2):

Total bench times are about the same.

[EDIT] First post updated
I can't reproduce it either with 4.0- 5319 compared to 4.0-5315.
(01-30-2015, 02:54 AM)JMC47 Wrote: [ -> ]Unable toe reproduce doing an every 100 build check on D3D. No noticeable spike down past the builds you reported. It's possible that adding in that option caused some kind of problem though, I will notify Armada.

(01-30-2015, 07:02 AM)Link_to_the_past Wrote: [ -> ]I can't reproduce it either with 4.0- 5319 compared to 4.0-5315.

Intel + NVIDIA combination, maybe that's why.

Someone needs to test the other 4: AMD + AMD/ATI, Intel + AMD/ATI, AMD + NVIDIA and Intel + Intel IGP (all with the latest GPU drivers), and maybe add an older Intel (Core2) CPU to the mix.
Pages: 1 2 3 4 5