Dolphin, the GameCube and Wii emulator - Forums

Full Version: JITARM64
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8
First, check if it's a JIT error by trying the cached interpreter. If so, try to disable some of the JIT instructions to figure out which instruction is broken. This is a bit tricky, but half of the issues can be checked by randomly disabling half of the instructions. But of course, first you must be able to compile dolphin on your own.

Let's see how often I'll write this text without anyone compiling dolphin on his own...
(03-02-2016, 07:47 AM)degasus Wrote: [ -> ]First, check if it's a JIT error by trying the cached interpreter. If so, try to disable some of the JIT instructions to figure out which instruction is broken. This is a bit tricky, but half of the issues can be checked by randomly disabling half of the instructions. But of course, first you must be able to compile dolphin on your own.

Let's see how often I'll write this text without anyone compiling dolphin on his own...

Thec umulation of optimizations in the last few builds have brought HUGE performance gains. HUUUGE. The build that fixed the slow to warm up higher GL + addi optimizations have pushed NSMB to 60 fps in most instances (even the intro with Peach and the birthday cake is getting around 50-55 fps and it used to be in the 20-40 fps range yesterday).
Wii Sports is almost a solid 60 for tennis.
Mario Kart Double Dash is 55-60 for every circuit of the Mushroom Cup with rare dips to 50.
Wind Waker is a solid 30 almost everywhere.
Luigi's head indeed exists now. Game runs 20-30 fps.
Waverace Blue Storm took a speed hit though and crashes when starting a race.
Mario Sunshine looks to be 25-30 in Delfino Plaza.
Wind Waker keeps crashing into the menu with a grey screen and it is really frustrating.
Sick of losing mundane progress and having to do THIS and THAT and AGAIN.
I am currently trying to get to the ghost ship after finally getting and opening the chart that lets you actually enter it.
This is on the pr 3689 build,but it was also happening on the previous one when leaving Hyrule after a LONG plot,that crash really hurt because I had to sit through it again and mash the button to advance text while needing to remember to save the instant I gain control.

Could this primarily be related to the shader cache storage not saving for some dumb likely Marshmallow reason?

Edit: Part of it could be related to memory when other apps were not force stopped since usually after I make sure many of them are stopped,it no longer crashes out randomly,as I got so much done in two crashless sessions after doing that.
The warping back and forth to trade all decoration stands with "not Gorons" while missing the correct one several times.

Looks like it may need memory priority to prevent nonsense causing crashes due to other apps being jerks.
(03-02-2016, 12:28 PM)Dauphin McDolphin Wrote: [ -> ]The build that fixed the slow to warm up higher GL
Seems like we were hit hard by the nvidia driver. They've stopped to advertice modern GL extensions, but once we've fixed this issue now, the new driver supports the threaded model by default (at least I think so). So yeah, there where some speedups within the arm jit, and now the correct configuration of the GL driver. In the end, compared to a month ago, this is a nice change Big Grin
The shaders are storing properly now,that's good,must have needed breaking in for Marshmallow or related to the high GL issue before it was worked around and/or fixed.

So the issue for Wind Waker crashing is likely memory related by priority or too much being used.
And I don't have any bulky multimedia apps installed like Kodi,I don't use that.

Edit: Brawl gave me panic alerts after long enough,before it,I played Special Brawl (Metal Heavy Fast Brawl) using Bowser against 3 Jigglypuff CPUs at lvl 1 on a custom collecting farm stage with only Pokeballs at high rate,then an all-star match to get shaders built up,and after that,a graphic glitched out for ready battle with a panic alert and the panic alert kept showing until I force stopped Dolphin.
I used P1 Bowser against a lvl1 CPU Jigglypuff in Special Brawl with Metal Heavy Slow Brawl,only Pokeballs at high rate,0.5 damage,score on,and 5 minute time match.
Trying to be as descriptive as possible,and enabled gecko codes are not likely the main cause since I never had an error with them on before,but,Generalized Super,Infinite Jumps Enabler,Infinite Jumps P1,and Unrestricted Camera.
(03-02-2016, 06:46 PM)degasus Wrote: [ -> ]Seems like we were hit hard by the nvidia driver. They've stopped to advertice modern GL extensions, but once we've fixed this issue now, the new driver supports the threaded model by default (at least I think so). So yeah, there where some speedups within the arm jit, and now the correct configuration of the GL driver. In the end, compared to a month ago, this is a nice change Big Grin

Stopped to advertice modern GL extensions?  What do you mean?  Have they changed the way linking to desktop OpenGL works?

ErAzOr

(03-02-2016, 07:47 AM)degasus Wrote: [ -> ]First, check if it's a JIT error by trying the cached interpreter. If so, try to disable some of the JIT instructions to figure out which instruction is broken. This is a bit tricky, but half of the issues can be checked by randomly disabling half of the instructions. But of course, first you must be able to compile dolphin on your own.

Let's see how often I'll write this text without anyone compiling dolphin on his own...

ia there a tutorial on how to disable JIT instructions? I couldn't find anything.
I'd love to help
I don't know it, but here's the steps I did to make a guess:

1) Opened https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/PowerPC/JitArm64/Jit.h

2) Located

Code:
void FallBackToInterpreter(UGeckoInstruction inst);


3) copied "FallBackToInterpreter" to clipboard, pasted to GitHub search field, searched

4) In query results, located Source/Core/Core/DSP/DSPEmitter.cpp:

Code:
if (!opTable[inst]->jitFunc)
{
   FallBackToInterpreter(inst);

Didn't seem to find anything usefull from this opTable, however

5) Also in the same query results you can see a table being inited like this in Source/Core/core/PowerPC/Jit64IL/JitIL_Tables.cpp:
Code:
static GekkoOPTemplate table4[] =
{    //SUBOP10
{0,    &JitIL::FallBackToInterpreter}, //"ps_cmpu0",   OPTYPE_PS, FL_SET_CRn}},


So from the looks of it, my guess is you go to https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/PowerPC/JitArm64/JitArm64_Tables.cpp and change the table entries like this:

{4,  &JitArm64:: DynaRunTable4}
to
{4,  &JitArm64::FallBackToInterpreter}
That's one way of going about it, although I would recommend not changing the dynarun table entries, since that might break things (And they aren't real instructions).
(03-04-2016, 12:19 AM)KHRZ Wrote: [ -> ]I don't know it, but here's the steps I did to make a guess:

1) Opened https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/PowerPC/JitArm64/Jit.h

2) Located



Code:
void FallBackToInterpreter(UGeckoInstruction inst);


3) copied "FallBackToInterpreter" to clipboard, pasted to GitHub search field, searched

4) In query results, located Source/Core/Core/DSP/DSPEmitter.cpp:



Code:
if (!opTable[inst]->jitFunc)
{
  FallBackToInterpreter(inst);

Didn't seem to find anything usefull from this opTable, however

5) Also in the same query results you can see a table being inited like this in Source/Core/core/PowerPC/Jit64IL/JitIL_Tables.cpp:


Code:
static GekkoOPTemplate table4[] =
{    //SUBOP10
{0,    &JitIL::FallBackToInterpreter}, //"ps_cmpu0",   OPTYPE_PS, FL_SET_CRn}},


So from the looks of it, my guess is you go to https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/PowerPC/JitArm64/JitArm64_Tables.cpp and change the table entries like this:

{4,  &JitArm64:: DynaRunTable4}
to
{4,  &JitArm64::FallBackToInterpreter}
1-3) good
4) DSPEmitter.cpp? That's our DSP. Wrong file
5) Jit64IL/JitIL_Tables.cpp? That's the Jit64IL backend. What about JitArm64/*_Tables.cpp?

This would be working, but the easier way is to look at this JitArm64 directory, and you'll see that every instruction starts with:
INSTRUCTION_START
JITDISABLE(bJITFloatingPointOff);
FALLBACK_IF(...);

So just add FALLBACK_IF(1); there, and it's done.
Pages: 1 2 3 4 5 6 7 8