Galaxy s7 edge crash

[Jaaan]

Alright things were looking good at first glance! Game loaded up fine all the way up to gameplay, still going strong past the meteor shower loading screen. but crashed at the start of the fight sadly.

A good thing is that it does seem to consistently load up until gameplay now! it will not crash anymore before that! Can't test it multiple times in the same instance though because the blocklink edit makes it crash if I close KH.

2nd time starting a new game went all the way past the meteor shower loading screen too but crashed at the start of battle again..

no more crashes at the start though!

Edit: Also strangely it looks like it did something else o.o looks like the game looks sharper or something.. could also be me. I've been looking at this for too long XD

anyways, I'm now trying it out with the blocklink on true just to see if that makes any difference. and it loaded past the start of the fight! also past the battle character select! I'm now at the story select! no crashes! loaded up Aqua's story, no crashes! this is looking very good! finished orb fight! No crash and at map select.. loading up castle of dreams.. no crash! I think this did it!*knocks on wood*

closed KH and reopened it to see what happened. got a black screen with controls on it that responded. closed PPSSPP and opened KH again, and it again, works fine! selected new game and am now again at the map select screen! 1st map loaded up fine too! closed KH and re opened it and the black screen thing didn't happen! Looking good!

I need to go to bed now.. I want to thank you for taking the time to do this, and if there's anything else that I can do let me know, I will be back tomorrow! I'm dedicated to making this work. I will zip up the APKs that I made and send them to you. maybe there's something you can do with it in the meantime. again thank you very much! This is really amazing that we went this far in one day! I also came to respect you devs much more. The time that goes into this is insane. I will get the gold version to support you guys!

I will PM the apks to you, and again if there's anything for me left to let me know!

cheers!

[[Unknown]]

No, thank you for testing. The hard part is really the trial and error in situations like this - we don't really know what's going on, so we have to probe the situation to figure out.

The test with block link on and the aligned code blocks sounds super good, but it's also super wasteful. Some games will hit performance problems because the jit cache space is being wasted so fast (games that run a lot of code every frame.)

Block linking is a good thing, but it's an optimization that only *sometimes* (well, most of the time) kicks in. I'm worried that if it crashes with it off, other games (or areas of this game) might crash even with it on. Even so, it's definitely major progress. We don't test with it off much, so I'm hoping there's just a bug happening when block cache is off.

If we can decrease the alignment a bit, it would really save space. Can you try this version?

Code:

while (((intptr_t)GetCodePtr()) & 0x3F) {
        HINT(HINT_NOP);
    }

(0xFF -> 0x3F)

If that works, we can try 0x1F or 0x0F too, which would waste even less space. My guess is that 0x3F is the lowest we can go, because that's the typical size of a cache line.

Another idea, that would be even better, is to disable that, and change the original code (from the post with instructions) to this:

Code:

void ARM64XEmitter::FlushIcacheSection(u8* start, u8* end)
{
    start = m_startcode + 4096 < start ? start - 4096 : m_startcode;
    end += 4096;
    while ((intptr_t)start & 0xFC) {
        start -= 4;
    }
    while ((intptr_t)end & 0xFC) {
        start += 4;
    }
#if defined(IOS)
    // Header file says this is equivalent to: sys_icache_invalidate(start, end - start);
    sys_cache_control(kCacheFunctionPrepareForExecution, start, end - start);
#else
#if defined(__clang__) && !defined(_M_IX86) && !defined(_M_X64)
    __clear_cache(start, end);
#else
#if !defined(_M_IX86) && !defined(_M_X64)
    __builtin___clear_cache(start, end);
#endif
#endif
#endif
}

This is a quick hack, but it aligns the start and end addresses of cache clears to 256. If aligning the cache clears is all that's needed, we don't need to waste space with the jit blocks. It'd be great if this option worked.

If it does, even better would be to reduce the three 4096s to like 256 or 64, or even 0. If it works with aligned clears with 0 padding, that would be awesome. There'd probably be nearly no performance penalty (some of this penalty is not immediately obvious... e.g. might cost more during loading than during actual gameplay, but both matter.)

All of this with block linking on.

Thanks again for the testing.

-[Unknown]

[Jaaan]

No problem! I figure it's the least I can do! I appreciate you taking the time to help me through this. I am learning a lot through this

(05-17-2016 12:45 AM)[Unknown] Wrote:  

Code:

while (((intptr_t)GetCodePtr()) & 0x3F) {
        HINT(HINT_NOP);
    }

(0xFF -> 0x3F)

This makes it crash again.. I am now trying the other 2 options just to see if it makes a difference, you never know.

0x1F also crashes. I got to the select memory card screen, second time I got to the disney screen. workaround works although performance seems to be less good than on 0xFF.

0x0F went the same as above, only when I used the workaround and loaded gameplay it crashed after taking a few steps. No loading screen.

Quote:Another idea, that would be even better, is to disable that

I'm assuming that means to just remove the code from the file? trying out now!

4096 crashed the first time I loaded it. Then I restarted PPSSPP and it works all the way, am now in the meteor shower cutscene. Performance is worse though. Random dips in framerate through gameplay. the orb fight dips to about 15-17 fps whereas on the debug1 it would stay smooth, like impressively smooth. Now trying out if lowering the numbers makes a difference.

256 does not run games. I get a black screen and PPSSPP becomes unresponsive. I can use the home screen button or delete it from ram though but it keeps happening. Same with 64 and also the same with 0.

Performance on the debug1 0xFF(the one from yesterday) was great though. I noticed some artifacts on black loading screens, and with KH having the phone go to sleep and re opening it made some walls disappear but if you switched screens it fixed itself, but gameplay was great! I tried valkyrie profile yesterday for a couple of minutes too and that also ran great. fps and speed both stay around 29-31 and 98-102% on all 3 games I've tried. Phone didn't seem to get hot either.[/code]

If there's anything else let me know I will keep checking this thread throughout the day!

EDIT: loaded up the APK from yesterday and it still is flawless. 1st time loading it loads straight to gameplay.

[[Unknown]]

Hmm, what about 0x7F? That's still a lot less wasteful than 0xFF, though still wasteful...

Well, the problem with 0xFF is just that when you only go to one area, it may seem great, but it's using up a lot of space for jit. There'll be more spikes going forward. If we have to use that method of alignment, we'll definitely only want to do it for this processor - wouldn't want to penalize other people for this CPU's flaws.

-[Unknown]

[Jaaan]

(05-17-2016 05:17 PM)[Unknown] Wrote:  Hmm, what about 0x7F? That's still a lot less wasteful than 0xFF, though still wasteful...

Trying out now! will edit later on with results! I take I also need to replace the code in arm64emitter with the old one from the instructions on page 2?

EDIT: No crashes with 0x7F! No noticeable fps drops either! I'm going to see how it performs at the orb fight. Orb fight also no performance issues! fps dipped to 27 like twice for a short second during the whole fight. played up until world one and walked around a bit. then switched to GW COL. Fastforwarded all the way up until gameplay, crashed just before that though. Then restarted PPSSPP, reloaded GOW, all went fine, gameplay loaded, also fast forwarded. performance was meh though, about 30fps/50%. closed that. opened Naruto Kizuna Drive. Fastforwarded that too(Might be the cause of the crash in both cases. But you know.. time.) crashed on the splash screens, re opened PPSSPP, continued loading from where it left, and went all the way up to gameplay. Closed the game and opened KH again, went from splash screens to main menu, started a game and no crash.

Seems like KH performs really well under these circumstances. any ideas for another game I could try?

EDIT 2: Removed PPSSPP from ram, am now opening each game I got and let it load until main menu, then close the game and load the next, see if crashes happen. Crashed on the 4th game. Trying again. Crashed on the third game. 3rd time it crashed immediately, but after re opening it picked up where it left.

0xFF I can load each game(9) I have until the main menu without crashes. Seems like I can close and load as much as I want and it won't crash.

EDIT3: Hmm.. well, I thought lets see if changing from option 1 to another one will make any difference if I then change the 0x value. I now changed it back to 0x3F, no changed to the emitter yet, and it loaded KH. No crash.. I'm going to try 0x0F again and see what it does.

0x0F also didn't crash now.. loads past the main menu fine. I don't even know anymore.

Okay so I played KH until you can choose who to fight as still before the orb fight. closed it and opened GOW. it loaded to the menu fine, closed that and opened dissidia 012, crashed after new game again, nothing new. then removed PPSSPP from ram and opened KH again and it crashed before the disney screen again. Removed it from ram again, and opened KH again, loaded past the disney screen but crashed before the main menu. did it again and it crashed immediately. and again, and it crashes before main menu again.

Went back to 0x3F, adb'd it, didn't use the APK. and now it crashes before the main menu again..

Now changed emitter64 to option 2 and jit64 on 0x3F. seems to work fine on first try. KH loaded fine. got gameplay. closed it. opened GOW, also loaded fine. crashed before gameplay though. removing from ram. KH crashed before main menu. keeps doing that now. Seems like on a fresh install it almost always works. after that it's hit or miss.

Seems like option 3 does not want to compile with the armjit changed to 0x3F.

Quote:Well, the problem with 0xFF is just that when you only go to one area, it may seem great, but it's using up a lot of space for jit. There'll be more spikes going forward. If we have to use that method of alignment, we'll definitely only want to do it for this processor - wouldn't want to penalize other people for this CPU's flaws.

Not sure what you mean with 'one area', but on the build from yesterday I managed to go from booting up the game(KH) all the way up to the first world without any noticeable performance issues. Like none. Tried this on 2 characters. I was sure that this was 'the fix'. I know next to nothing about programming though so what goes on behind the scenes goes above my head. Gameplay was fine though!

Found one game that I didn't manage to get running though on the build from yesterday, which is FF Dissidia 012. Goes all the way up until the main menu screen, crashes after selecting new game. Could also be the iso though, not completely sure.

Tried some others too, which all loaded fine to gameplay, GOW COL, Naruto Ultimate NInja Impact and FF Type-0

GOW and FF had low fps though on 2x 2x resolution.

Anyways, coming back with results in a minute, will edit the top part.

EDIT: Btw, need me to try the 0x edits with blocklink off too or no?

[[Unknown]]

Interesting, it sounds like +/- 4096 (typical size of a page) and the 256 alignment (which seems large for a cache line) are working best. To confirm, with option 1 + 0xFF (which is the 4096 + 256 option), you haven't gotten any crashes?

Unfortunately, I don't feel 100% confident in this since the two components seemingly required don't seem related, and it doesn't totally make sense. I'm a little concerned that 256 is just leaving enough holes that it's significantly less likely to crash, but will eventually still crash. But, I'm not sure what else to try... Henrik?

Actually, I had one more idea. Instead of that one HINT part, what if you try:

Code:

for (int h = 0; h < 64; ++h) {
    HINT(HINT_NOP);
}

This will do a different thing than before. If this works also, it may mean that what we really need is space between blocks, not alignment. Since most blocks are pretty small, it might be that alignment was just giving us space.

If that does work, can you try 32 and 16 also, in place of 64? If it doesn't, there's no need to bother. If 64 doesn't work, those others are very unlikely to work.

The next thing is, what does it show under System Info? We might have to do this based on the "Name" under "CPU Information", I suppose.

I don't think it's interesting to try the other alignment values with block link off. If 0xFF works reliably and 0x3F doesn't, I don't expect that to be impacted by block linking.

---

To explain a bit about what's happening and what you're debugging -

Jit breaks the game's code into small pieces, called "basic blocks." These are typically short sections of MIPS code (that's the CPU the PSP has.) Then it translates that basic block into ARM64 code (which is what your phone's CPU uses.) Then the pieces of the program are stored in memory as jit blocks.

Normally, CPUs can count on program code not changing - sometimes they don't even look at the code, because they just want to go fast. They just run the program from "the instruction cache," which is like saying it knows the program by heart. When we change the code, we have to tell it - or it just won't know. This is what "invalidation" is.

Normally, after writing new code, we tell the operating system - I started writing new code HERE, and I finished with the new code HERE. So forget anything between those two places. The 4096 change makes us lie: we say we invalidated 1024 more bits of program code each direction than we really did.

Basic blocks are really small, but there's lots of them. 4096 bytes / 1024 instructions will probably cover many blocks. This will hurt performance (more or less depending on different CPUs), but usually only temporarily.

Block linking is a trick where we tie blocks together, directly. With block linking off, we run one block at a time. There's overhead while the jit reaches into its bag to pull out the next block. But sometimes, code goes in sequence - we can just send the CPU from one block directly to the next. To do this, after we've created both blocks, we go back and modify the first one to point directly to the second. This invalidates again (and with the changes, also invalidates +/- 1024 instructions.)

Lastly, the alignment makes it so every block starts at an "even" position. It's like if you started paragraphs on lined paper, only on every 5th line. If your first paragraph was 6 lines long, oh well, you'll just skip 4 lines to start the next one.

My big worry is that, aligning to 256 might mean that most blocks have a bunch of blank lines between them. This wastes the limited jit space some, but more importantly it could be it's only working when there's enough blank space between all blocks. Maybe the CPU really just wants two blank lines between each paragraph. Sometimes (it's not common), there will be larger blocks, and it could be these will still crash (i.e. when a boss uses an unusual and complicated move, or etc.)

-[Unknown]

[Jaaan]

Quote:To confirm, with option 1 + 0xFF (which is the 4096 + 256 option), you haven't gotten any crashes?

0xFF does not crash. I can check it out again if you like. But I haven't experienced any crashes with it as of yet. Like I said, where I could load maybe 3 or 4 on the 0x7F, 0xFF I could close and open as many as I want and let it load to the main menu.

I don't see a 256 in the emitter code though, nor in the armjit. Option one only uses 4096. The other options don't have a 256 in them either

Code:

for (int h = 0; h < 64; ++h) {
    HINT(HINT_NOP);
}

On this now!

Okay did that. First time loading KH, everthing looks fine. Loads to the main menu fine. Starting a new game, also fine. Loads up to gameplay fine too Now to quickly get to the orb fight and see if there are any issues. Orb fight went fine No crashes as of yet. Haven't noticed any artifacts on the loading screens either. World 1 loads fine, walked around for a bit.

Now to close the game and open another. Loaded GOW, no crash yet Woops, only pressed back, and then continue and ppsspp froze, no crash though.

Now I'll try to load as much games as I can to the main menu and see if any crashes happen with that. Looks like nine games load to the main menu fine without crashes. Yup. and then starting over at game 1 won't make it crash either!

I'm gonna play to the orb fight one more time and change games to see what'll happen, then I'm gonna try it with 32. 2nd time went fine too, KH performed without issues all the way up to world 1 again. This was in the same instance where I opened all those games, so PPSSPP was still in ram.

Now to close it and open another game. Game opened. Loads the main menu fine, starting a new game gives gameplay Opening GOW now, loads fine too, no crash after main menu. Gameplay loads up fine also! And then closing that and opening another game again, also no crash.

Now off to try it with 32! 32 loaded up, gonna have to go do some errands, will try some stuff in the meantime and will be back soon.

Seems like 32 works just as good as 64! Didn't crash once and did the same things as with 64 mostly.

Now off to try 16! Fingers crossed.

Alright so 16 doesn't get me gameplay. Crashes before the main menu on most games, otherwise just after. The workaround works but as soon as it gets a chance to load it crashes. Going back to 32 and see if it eventually crashes.

Okay played all the way to the first boss on Aqua's story, the pumpkin car thing. Died there though. No crashes! All the way from loading up to the game to that point! Now going to switch to another game and see what happens.

Ninja impact loads up to gameplay all the way fine too! Now trying out another game. Type-0 also gets me gameplay! all in the same instance too! And the performance on type-0 is somehow better than on the build with 0xFF.

Anyways looking good, this one! Haven't noticed any differences between 0xFF and 32.

Kizuna Drive and GOW both also loaded up gameplay fine, and was able to play around for a while. Not one crash on 32.

Btw people if you are following this, which I know you are since the views keep climbing up , look at the bottom section of the post above and realize how much effort goes in to this! That is only a small fraction of what it takes to get this running, these people really deserve any support you can give them for what they do. They are doing this in their own free time and as you can see it comes with A LOT of trial and error. If you can, please support these guys!

Not trying to force anyone btw. Just saying

Almost forgot: Name under CPU information = Unknown

lol

Still no issues with 32

For the heck of it I replaced the arm64emitter code to the original un-edited version, without the 2 lines of extra code, and with the for loop this also works! Getting gameplay on KH on first try! No crash on meteor shower. No crash after tutorial fight. No crash on orb fight and performance is good. some dips though. first map also loads fine. going to keep using this and see how it performs.

It crashed upon closing KH and opening GOW, it loaded some and crashed before the main menu. Re opened PPSSPP and it reloaded GOW and it loads fine now. Nah, not as good as with the 2 lines of code. It crashed 2 times already.

Well I loaded back the one with the 32 for loop and no issues. Performance is just as good as the one with the while loop.

[Bobby_Flamingo]

I would like to thank you guys so much for all the effort you have put into getting this to work for all of us who love this app, but don't have the the level of technological skill to get this going properly by tinkering with the code. You da real MVP!

The moment I get PPSSPP running on my S7 I will be buying Gold!

[[Unknown]]

Can you run "adb shell cat /proc/cpuinfo" and paste the output inside [ code ]? Here's what I get on a Nexus 5:

Code:

Processor       : ARMv7 Processor rev 0 (v7l)
processor       : 0
BogoMIPS        : 38.40

processor       : 1
BogoMIPS        : 38.40

processor       : 2
BogoMIPS        : 38.40

processor       : 3
BogoMIPS        : 38.40

Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x51
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0x06f
CPU revision    : 0

Hardware        : Qualcomm MSM 8974 HAMMERHEAD (Flattened Device Tree)
Revision        : 000b
Serial          : 0000000000000000

(if you happen to have any "serial" value I suppose you can remove it, though I doubt there's much danger to exposing it.)

The most interesting part above is "Hardware" in my output. That's the chip in a Nexus 5. Ideally, it would mention "Exynos 8890" in it somewhere, which is the misbehaving chip in your hardware, I think...

-[Unknown]

[jakal7x]

(05-22-2016 01:40 AM)[Unknown] Wrote:  Can you run "adb shell cat /proc/cpuinfo" and paste the output inside [ code ]? Here's what I get on a Nexus 5:

Code:

Processor       : ARMv7 Processor rev 0 (v7l)
processor       : 0
BogoMIPS        : 38.40

processor       : 1
BogoMIPS        : 38.40

processor       : 2
BogoMIPS        : 38.40

processor       : 3
BogoMIPS        : 38.40

Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x51
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0x06f
CPU revision    : 0

Hardware        : Qualcomm MSM 8974 HAMMERHEAD (Flattened Device Tree)
Revision        : 000b
Serial          : 0000000000000000

(if you happen to have any "serial" value I suppose you can remove it, though I doubt there's much danger to exposing it.)

The most interesting part above is "Hardware" in my output. That's the chip in a Nexus 5. Ideally, it would mention "Exynos 8890" in it somewhere, which is the misbehaving chip in your hardware, I think...

-[Unknown]

Let me answer of your request. It's Galaxy S7 Exynos version.
S7 has same AP with S7 edge as far as i know.
By the way, unfortunately, there is nothing to describe hardware part about Exynos 8890..
So, i'm not sure it helps you to fix PPSSPP for galaxy S7, but i hope so.
If you need some information of Galaxy S7 more, please replay here. I will provide what you want as possible as i can.

P.S I am sorry if you wouldn't understand my english.

[[Unknown]]

Hmm, we might be able to use the part number for Samsung. I'm worried because it's "1" but I suppose it may be their first chip.

How about this command?

adb shell grep -e dalvik -e product /system/build.prop

Hard to tell how this will affect future products utilizing Mongoose CPUs...

-[Unknown]

[cha0tic]

Nice work guys I was suppose to help with the debugging as well but got busy Irl and haven't had much time to sit down and fiddle around.
Looking forward to a solution going on

[jakal7x]

(05-22-2016 03:13 PM)[Unknown] Wrote:  Hmm, we might be able to use the part number for Samsung. I'm worried because it's "1" but I suppose it may be their first chip.

How about this command?

adb shell grep -e dalvik -e product /system/build.prop

Hard to tell how this will affect future products utilizing Mongoose CPUs...

-[Unknown]

Here you are

[[Unknown]]

Great, wrote some detection based on that:

https://github.com/hrydgard/ppsspp/pull/8769

This uses the 32 NOP padding and the 4096 byte over-invalidation, which seems to be the best option that got no crashes. Definitely an ugly hack, though.

-[Unknown]

[Henrik]

Nice investigation! I still don't understand why other JITs like Javascript in browsers work, but this might have to do for now..