Emulator

I'm starting to suspect a driver issue. D3D12 crashes in the same place, i switched to OGL and after say 15mins of playing, it black screened. I'll try 5.0 stable once I set-up my wiimote (was using controller + relative wiimote pointer)

iwubcode wrote:

I'm starting to suspect a driver issue. D3D12 crashes in the same place, i switched to OGL and after say 15mins of playing, it black screened. I'll try 5.0 stable once I set-up my wiimote (was using controller + relative wiimote pointer)

I just want to comment on my previous statement. While I know Ishiiruka is not supported, it does not have this issue in either D3D12 or Vulkan. While it might still be driver related (since no one else seems to indicate they have the issue), it does seem to be code dependent.

I just tried it with dev build Dolphin 5.0-1333 with the same result (crash on D3D12/Vulkan selecting galaxy, crash on OGL after ~15mins of playing). D3D11 doesn't seem to have these issues. Also, worth noting that I updated my graphics drivers to 16.11.4 a few days ago.

Bugs like this can be tricky to debug, since as far as I'm aware none of the dev team has a Polaris card to reproduce the issue with. I'd guess it'd be an issue with the shaders if it's affecting multiple backends. Ishiiruka has a fair few differences in their shadergen code (mostly less accuracy over master), which could explain the difference.

Can you please test if the issue occurs on 5.0-1230 (last build before XFB was merged for Vulkan), as well as with PR 4462 (https://github.com/dolphin-emu/dolphin/pull/4462 / https://dl.dolphin-emu.org/prs/pr-4462-dolphin-latest-x64.7z), which might help in narrowing down what the problem is.

Stenzek wrote:

Bugs like this can be tricky to debug, since as far as I'm aware none of the dev team has a Polaris card to reproduce the issue with. I'd guess it'd be an issue with the shaders if it's affecting multiple backends. Ishiiruka has a fair few differences in their shadergen code (mostly less accuracy over master), which could explain the difference.

Can you please test if the issue occurs on 5.0-1230 (last build before XFB was merged for Vulkan), as well as with PR 4462 (https://github.com/dolphin-emu/dolphin/pull/4462 / https://dl.dolphin-emu.org/prs/pr-4462-dolphin-latest-x64.7z), which might help in narrowing down what the problem is.

Well unfortunately, I tried various dev builds as far back as 970~ and even stable 5.0 and they all exhibit the same issue (in DX12 and Vulkan where available).

What kinds of things would you look at if you were debugging this? With the holidays coming it might be tough for me to find time but I can potentially look at the code and debug it.

If you feel like doing some debugging work, it's sometimes possible to narrow down issues like these without looking at the code.

If the problem occurs consistently, you can try recording a long fifolog (on a machine/backend that doesn't crash), say 600 frames (10 seconds at 60hz), get it as close as possible to the crash point, it might be worth using frame stepping or slowing the emulation speed down, keep in mind a long fifolog can easily be hundreds of megabytes.

If playing back this fifolog causes the emulator to crash, you can start reducing the range of frames, then objects until it doesn't crash, then increase it to find the object that causes it to crash. From that we can likely figure out which shader in particular is causing the issue, and make a guess as to what the issue is.

No guarantees this would work though, as not all issues are reproducible with fifologs.

Stenzek wrote:

If you feel like doing some debugging work, it's sometimes possible to narrow down issues like these without looking at the code.

If the problem occurs consistently, you can try recording a long fifolog (on a machine/backend that doesn't crash), say 600 frames (10 seconds at 60hz), get it as close as possible to the crash point, it might be worth using frame stepping or slowing the emulation speed down, keep in mind a long fifolog can easily be hundreds of megabytes.

If playing back this fifolog causes the emulator to crash, you can start reducing the range of frames, then objects until it doesn't crash, then increase it to find the object that causes it to crash. From that we can likely figure out which shader in particular is causing the issue, and make a guess as to what the issue is.

No guarantees this would work though, as not all issues are reproducible with fifologs.

Huh didn't even know this was possible. How do you record a fifolog?

Unfortunately, the only machine that I have is a very very old windows xp machine. Could anyone on the dev team provide a fifolog for me to replay?

I also haven't tried a non-ishiiruka build in a while, I'll try the latest this weekend.

iwubcode wrote:

Unfortunately, the only machine that I have is a very very old windows xp machine

Probably goes without saying but I meant "only other machine"

(odd there's no way to correct an old comment)

iwubcode wrote:

This single frame from Mario Galaxy is what causes the crash! Going to try and work on wittling it down to a range of objects for Stenzek.

I slowly incremented the object counter and it crashed when I hit object 10.