Project

General

Profile

Actions

Emulator Issues #10499

closed

Major slowdown due to "WFS updates"

Added by ryanebola16 about 7 years ago. Updated about 7 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Current
Regression:
Yes
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
5.0-5291
Fixed in:
5.0-5314

Description

Game Name?

Super Smash Bros. Brawl

Game ID? (right click the game in the game list, properties, info tab)

RSBE01

MD5 Hash? (right click the game in the game list, properties, info tab, MD5 Hash: Compute)

Edited ISO, works fine on both Dolphin and real Wii. Only the music files were edited.

What's the problem? Describe what went wrong.

After merging PR 5941, Brawl's speed has dropped below 100% with an unlimited frame rate cap and all codes disabled
5.0-5291 - 62%
5.0-5264 - 161%
The slowdown ruins this game.

What steps will reproduce the problem?

  1. Set frame cap to unlimited
  2. Start a match with two Marios on Final Destination
  3. Observe the massive frame rate drop

It is important to make sure the bug hasn't already been fixed. Please tell us what the latest version you've verified the bug on.

5.0-5306: SLOW
5.0-5291: SLOW
5.0-5264: FINE
5.0-5261: FINE

What are your PC specifications? (CPU, GPU, Operating System, more)

Win 10 Pro x64
Intel Core i7-4702MQ CPU @2.20GHz
GeForce GT 750M
GeForce Game Ready Driver 384.94


Files

WFS.PNG (1.59 MB) WFS.PNG ryanebola16, 08/25/2017 02:43 AM
PerfPro.part1.rar (5 MB) PerfPro.part1.rar Performance Profiler Output (1/3) ryanebola16, 08/25/2017 03:35 AM
PerfPro.part2.rar (5 MB) PerfPro.part2.rar Performance Profiler Output (2/3) ryanebola16, 08/25/2017 03:35 AM
PerfPro.part3.rar (2.86 MB) PerfPro.part3.rar Performance Profiler Output (3/3) ryanebola16, 08/25/2017 03:36 AM
RevHist1.PNG (102 KB) RevHist1.PNG Reverting latest commits thorugh "WFSI: Implement patch install" makes the problem go away ryanebola16, 08/25/2017 02:12 PM
CopyDir.PNG (102 KB) CopyDir.PNG ryanebola16, 08/25/2017 03:01 PM
Actions #1

Updated by JMC4789 about 7 years ago

meh

Actions #2

Updated by delroth about 7 years ago

Yeah... I'm going to say you're testing this wrong, because this PR literally has no way of impacting code paths outside of WFS, AFAICT.

Actions #3

Updated by Helios about 7 years ago

  • Status changed from New to Questionable
Actions #4

Updated by ryanebola16 about 7 years ago

I redownloaded the following PRs and got the same results:
5.0-5291: SLOW
5.0-5264: FINE

Can someone try to reproduce the problem?

Actions #5

Updated by JMC4789 about 7 years ago

I followed your exact steps and performance is exactly the same, 120 - 140 fps on master, 120-140 fps on 5.0-5264

Actions #6

Updated by ryanebola16 about 7 years ago

I'll add this image to show I'm not going insane.

Actions #7

Updated by JMC4789 about 7 years ago

If you can, download visual studio, compile the build before/after WFS, and do the performance analysis, and show us the different hot paths. That'll tell us what is making it slower for you.

Actions #8

Updated by JMC4789 about 7 years ago

There's a guide on how to compile on the github page, and I'll try to provide any extra assistance I can.

Actions #9

Updated by JMC4789 about 7 years ago

Have you tried running them separately? It seems as though Windows schedules the selected app to get more performance considerations than background ones. In you screenshot, the old build is selected, meaning it would run significantly faster.

Actions #10

Updated by ryanebola16 about 7 years ago

Oops, I forgot to mention that I photoshoped that image. Each build was run separately. I'm looking into performance profiling now.

Updated by ryanebola16 about 7 years ago

I've added the Performance Profiler output for my two branches: PREWFS and WFS. I included an image of the split to make sure I did it right.

Stupid 5MB limit...

Actions #12

Updated by ryanebola16 about 7 years ago

And for both profiler output runs, I completed a one stock match mario vs mario on final destination then closed Dolphin.

Actions #13

Updated by JMC4789 about 7 years ago

Another thing you can do is bisect to commits inside of WFS merge if you're compiling yourself, which could be super useful!

Actions #14

Updated by ryanebola16 about 7 years ago

Unfortunately the commits appear to be dependent upon each other. I tried reverting a few of them individually but each one would crash the emulator.

Actions #15

Updated by JMC4789 about 7 years ago

Fair enough, thank you for the attempt!

Actions #16

Updated by JMC4789 about 7 years ago

Checked your performance logs, the slowdown appears to be in the D3D Async compiler... can you try OpenGL/Vulkan?

Actions #17

Updated by ryanebola16 about 7 years ago

I could reproduce the problem on DX11 and OGL. Could not reproduce on Vulkan.

Actions #18

Updated by JMC4789 about 7 years ago

It sounds like this is completely unrelated to WFS and more likely something going on with your computer not liking the new exes.

Actions #19

Updated by ryanebola16 about 7 years ago

Building without a debugger helped me get around some access violations.

For the WFS Updates pull request merge:
Reverting the latest commits through WFSI: Fix the TMD size check did not fix the problem.

I then reverted "WFSI: Implement patch install" finalization and the problem is no longer present.

See RevHist1.png for my history of changes.

Actions #20

Updated by JMC4789 about 7 years ago

So, I relooked at your performance graph, the D3D thing had to do with ubershaders compiling. I have no idea why Vulkan isn't affected, that commit shouldn't cause a slowdown.

Actions #21

Updated by ryanebola16 about 7 years ago

I had Ubershaders set to hybrid for all of the tests I have done for this issue. I set Ubershaders to Disabled and retested. It did not make a difference.

Actions #22

Updated by JMC4789 about 7 years ago

Like I said, it was just throwing it off, I filtered it and now they're mostly identical.

Actions #23

Updated by JMC4789 about 7 years ago

Can you put a breakpoint on File::CopyDir and see if it ever gets hit while you're playing.

Actions #24

Updated by JosJuice about 7 years ago

For the reference, File::CopyDir is in Source/Core/Common/FileUtil.cpp.

Actions #25

Updated by ryanebola16 about 7 years ago

Am I doing it right?

Actions #26

Updated by JosJuice about 7 years ago

Yes, the breakpoint has been set up correctly, and it has also been triggered. (Though it seems like it got triggered when you're starting Dolphin, and we're only interested in if it gets triggered when running the game.)

Actions #27

Updated by ryanebola16 about 7 years ago

I needed to silence access violations to be able to use the debugger but that breakpoint was not triggered during gameplay.

Actions #28

Updated by sepalani about 7 years ago

Is your issue fixed if you replace this code in FileUtil.cpp line 571

    else
    {
      Rename(source, dest);
    }

with:

    else if (destructive)
    {
      Rename(source, dest);
    }
Actions #29

Updated by ryanebola16 about 7 years ago

Oh wow that does fix it! (tested all video backends, re-enabled codes, and re-enabled hybrid Ubershaders)
Thanks!

Actions #30

Updated by JosJuice about 7 years ago

  • Status changed from Questionable to Fix pending
  • Milestone set to Current
  • Regression changed from No to Yes
  • Regression start set to 5.0-5291

https://github.com/dolphin-emu/dolphin/pull/5980

I don't know how that change fixes the issue, but it's a change that makes sense, so...

Actions #31

Updated by JosJuice about 7 years ago

  • Status changed from Fix pending to Fixed
  • Fixed in set to 5.0-5314

https://dolphin-emu.org/download/dev/a861c5772d3a36d55a7bef1dc7481f620460ff07/

Thanks for all the help with tracking the issue down.

Actions #32

Updated by Helios about 7 years ago

(╯°□°)╯︵ ┻━┻

Actions

Also available in: Atom PDF