Native Mac Testing Build

[Shrimpbob]

Blame the CLOCLIP.
and no, there's no fix ATM Sly series tend to eat your GPU alive, even on windows version.
So, on a macbook.... I let you imagine

Right, I get that. But the Xenosagas did work on my old computer, just crappily. Now they crash the emulator entirely on the M1 in software mode, even though other graphically-intensive games like DQVIII run just fine. Is it just that some games have stuff in them that don't jive with other things?

[jesalvein]

Is it just that some games have stuff in them that don't jive with other things?

you have no idea....

basically ps2 sdk gave access to devs to real hardware, letting them do some real weird stuff.
emulating then becomes a nightmare

[StLouisCPhT]

Blame the CLOCLIP.
and no, there's no fix ATM Sly series tend to eat your GPU alive, even on windows version.
So, on a macbook.... I let you imagine

Sly actually isn’t the worse thing to try to run on an M1 MacBook Pro. It IS miserably slow but is better with the recent build vs the older ones from last year.

Shrimpbob, you are running PS2 software on a x86_64 based emulator on an ARM based machine. Trying to compare that to your previous setup.... that way lies madness.

[TellowKrinkle]

Right, I get that. But the Xenosagas did work on my old computer, just crappily. Now they crash the emulator entirely on the M1 in software mode, even though other graphically-intensive games like DQVIII run just fine. Is it just that some games have stuff in them that don't jive with other things?

To be clear, I do consider the emulator crashing here a bug.  I've gotten a crash dump from one other user on a similar SW renderer crash, and the crash appears to be inside code outputted by the SW renderer's JIT, which is hard to debug because it means I can't use the address of the instruction to look up what function it was in.

If you want to help debug this, you can run PCSX2 in LLDB, make it crash, and send me the disassembly (disassemble --start-address beginning_of_function --end-address end_of_function) of the function it crashed in along with a printout of the processor's registers (register read), though this will be a little hard since you'll have to find the start and end of the function manually by poking around the crashing address (LLDB won't be able to find it in JIT-generated code).  You're looking for a push rbp; mov rbp, rsp; to start the function, and pop rbp; ret; to end it.  I'll be extra happy if you settings set target.x86-disassembly-flavor intel first.

I plan to include a debug information generator in the next release, which will tell LLDB where the function starts and ends to make this process easier

Also try setting the number of SW renderer threads to 0 or 1 to see if it's a threading issue

[Shrimpbob]

To be clear, I do consider the emulator crashing here a bug.  I've gotten a crash dump from one other user on a similar SW renderer crash, and the crash appears to be inside code outputted by the SW renderer's JIT, which is hard to debug because it means I can't use the address of the instruction to look up what function it was in.

If you want to help debug this, you can run PCSX2 in LLDB, make it crash, and send me the disassembly (disassemble --start-address beginning_of_function --end-address end_of_function) of the function it crashed in along with a printout of the processor's registers (register read), though this will be a little hard since you'll have to find the start and end of the function manually by poking around the crashing address (LLDB won't be able to find it in JIT-generated code).  You're looking for a push rbp; mov rbp, rsp; to start the function, and pop rbp; ret; to end it.  I'll be extra happy if you settings set target.x86-disassembly-flavor intel first.

I plan to include a debug information generator in the next release, which will tell LLDB where the function starts and ends to make this process easier

Also try setting the number of SW renderer threads to 0 or 1 to see if it's a threading issue

I won't lie, other than the renderer thread thing, the rest of this is Greek to me. If you can give me a step by step on how to debug the crash, I'd be more than happy to but I don't super understand what you mean.

EDIT: Also checked it, it's not a threading issue. Still crashes with 0 or 1. The game starts up and the first cutscene plays but as soon as it leaves the first cutscene, it crashes.

[StLouisCPhT]

I won't lie, other than the renderer thread thing, the rest of this is Greek to me. If you can give me a step by step on how to debug the crash, I'd be more than happy to but I don't super understand what you mean.

EDIT: Also checked it, it's not a threading issue. Still crashes with 0 or 1. The game starts up and the first cutscene plays but as soon as it leaves the first cutscene, it crashes.

Try to eject all virtual memory cards then start it and see if it still crashes anywhere in the game.

[Shrimpbob]

Try to eject all virtual memory cards then start it and see if it still crashes anywhere in the game.

Whoa, this actually worked! I combined it with setting threading 1 and turning off Mipmapping, Auto Flush, and Edge Anti-Aliasing and now it's running! Yay! Thank you so much for the help.

[StLouisCPhT]

I figured that was the issue. Same with my system. Something is affecting the "Your System Data" file on the memory cards and preventing SW mode from working properly. Deleting the file and allowing it to be recreated will work for a while but then it will start acting up again.

I informed TellowKrinkle of this yesterday and I am just waiting for a reply.

[Shrimpbob]

It's now working fine even with the memory card in with Mip, Flush, and Edge disabled. I guess just a matter of time for waiting until the next crash then?

[StLouisCPhT]

It's now working fine even with the memory card in with Mip, Flush, and Edge disabled. I guess just a matter of time for waiting until the next crash then?

Maybe? Let me do some tests.

Edit: Okay, so it seems that mipmapping was causing the crash in XenoSaga when using sw rendering. I have not been able to reproduce any issues with that disabled.

Edit 2: It also seems that mipmapping is responsible for messing up the "Your System Data" file on memory cards and causing PCSX2's sw renderer to crash during start up with Fast Boot disabled.

Edit 3: @jesalvein Sly Cooper and Thievious Raccoonus runs at 90-100% speed on my M1 using sw rendering (now that I can actually use sw rendering). Haven't tried the others yet.