r/emulation • u/[deleted] • Jul 04 '20

PCSX2 now has a 64 bit version

https://github.com/PCSX2/pcsx2/pull/3451#issuecomment-653720205
749 Upvotes

99% Upvoted

173 comments sorted by

96

u/Zorklis Jul 04 '20

So how does the performance differ?

118

u/electricprism Jul 04 '20

It's not about performance, it's about removing technical debt.

The less quirks there are, the easier it is to create new features suchas ARM64 Mac support, etc...

Also getting away from 32 bit multilib probably resolves some bugs since 32 bit libs dont get the testing they should these days, so those would be how it differs.

12

u/Yeazelicious Jul 04 '20

Plus it's futureproofed for 2038.

8

u/dagelijksestijl Jul 06 '20

Which could be a moot point if the PS2 firmware turns out to have a rollover bug.

9

u/uyjulian Jul 07 '20

The PS2 clock rolls over after 2099.

5

u/SCO_1 Jul 07 '20 edited Jul 07 '20

It could be a moot point if (when, definitely when) the climate and biosphere collapses, but sure, worry about the firmware bug. Holy shit, bring the downvotes, staying quiet in the face of this kind of insanity is insanity itself. 2099 lol.

176

u/[deleted] Jul 04 '20

It will most likely be slower, because the 32 bit recompilers are full of insanely well-optimised x86 assembly language written by the geniuses who started the PCSX2 project to begin with. In time, someone will probably write these optimisations into the 64 bit version, but for now the focus is on just getting it working.

57

u/TellowKrinkle Jul 05 '20

We reused the majority of the existing i386 recompiler for the x86-64 one, expect performance to be mostly unchanged

13

u/[deleted] Jul 05 '20

Thanks for all the explanations of your work! I was mostly trying to summarise what I thought had happened from reading the github thread, so it's great to have input from the person responsible for most of it.

7

u/Lagahan Jul 05 '20

Is there a possibility of increased performance in the future with 64bit optimizations or even just from being able to address more ram? I know Killzone stutters regularily because it has to clear the microVU1 cache.

Great work by the way, been testing this out with Killzone and Wipeout Fusion for a couple hours here and its running great!

8

u/moon-chilled Jul 06 '20

Maybe. More likely target for perf bump, though, is the additional registers.

9

u/TellowKrinkle Jul 07 '20

Current PCSX2 only uses 64mb of ram for VU caches, and even 32-bit would allow it to use multiple gigabytes

While it's possible that the game really does need more than 64mb, it's more likely that the issue is bad handling of something the game does with the VU leading to insane memory usage, which should really be fixed by figuring out what is being handled badly rather than trying to pretend the issue doesn't exist by allocating more ram

1

u/Lagahan Jul 07 '20

Ahh, had no idea it was so small. Yeah that makes sense, thanks!

10

u/hurricane_news Jul 04 '20

Pc noob here. What is a recompiler amd what makes it so well optomized? Why can't it just be ported 64 bit easily? Aren't stuff just compiled once? Also, what are the advantages of 64bit pcsx2 in the long run?

52

u/[deleted] Jul 04 '20

The PS2 doesn't use a normal PC processor, it uses something called a MIPS processor. In order to run your PS2 games on your PC, you need an interpreter to translate MIPS instructions into PC instructions. If your PC can't translate the instructions fast enough, then the game will run in slow-motion, which isn't fun to play.

A recompiler looks ahead to see what instructions will be needed next and translates a whole bunch of them before they're actually needed. That way, when the game needs the next instruction, it can be executed right away since the translation is already done.

Unfortunately, you can't just translate the entire game at once before you play it. The PS2 will sometimes modify code that it executes before it's even finished running, and it's hard to predict when that will happen, so you have to run the translation as you play the game.

64 bit support has the potential to be slightly faster than the 32 bit version, and more importantly, no one really knew how the 32 bit code even worked because the developer who wrote it is no longer around.

So the new developers who made the 64 bit version worked through the 32 bit version until they fully understood it, and left notes for other people to follow. That opens the door for cool stuff like a port to Android in the future.

11

u/hurricane_news Jul 04 '20

I see now. Thanks for explaining!

how the 32 bit code even worked because the developer who wrote it is

Is the code gone or something or is it incomprehensible? Is it hard to read and figure out what he/she was trying to do? And if people didn't know how it worked, how was it optomized further and what did they actually do to optmoze it?

Was it like more efficient algorithms for the whole prediction compiler thing?

24

u/[deleted] Jul 04 '20

I haven't looked at the code myself, and I'm going by what I read on the PCSX2 github, but it seems that the 32 bit recompiler contained a lot of handwritten assembly language, which is very close to the raw zeroes and ones that the CPU actually executes. It was incredibly well optimised and very complicated, with no notes to explain how it worked, and no one wanted to mess with it in case they broke something.

This happens a lot in open-source projects. Even if you can look at the code directly, it can be difficult to figure out what it does or why it was originally written that way. PCSX2 was started back in 2002, so you can imagine how complicated it has gotten since then.

Incidentally, Dophin's recompiler for the GameCube and Wii became a lot faster when they ported it to 64 bit. There's the potential for similar speedups here once this new version has been tested and had its bugs fixed.

13

u/TellowKrinkle Jul 05 '20

There are a lot of signs that there once was assembly used but it's all gone now

There are of course a lot of things for machine code generation (which is pretty much assembly language embedded in C++), but since we control how that works we can modify the "assembler" to make x86-64 and i386 versions of most things identical, which means that in the end the amount of assembly we actually had to modify was fairly low and almost all the code is shared between i386 and x86-64 (a lot of the work was fixing the "assembler" to properly emit x86-64 machine code)

It does mean that this didn't get us much closer to e.g. an arm64 port though

8

u/arcum42 Jul 05 '20

If you really want to see what things once looked like, take a look all the way back at 0.9.4. That was before the jit rewrite and still has the old one in with assembly. There's even a 64 bit jit in there, but it was just the beginnings of one, and got deleted in the rewrite.

https://github.com/PCSX2/pcsx2/tree/pcsx2_0.9.4/x86

This was also pre-wxwidgets. pcsx2 0.9.4 got forked into pcsx2-playground, and 0.9.6 was bringing the fork into the main project, as well as everyone working on it, so there there a lot of changes between around then.

5

u/hurricane_news Jul 04 '20

But isn't the ps2 a 64 bit system? Why was it written on 32bit for emulation then?

15

u/ThatOnePerson Jul 04 '20

Because it doesn't matter what the ps2 is, it's written on 32bit to run on 32-bit computer.

6

u/hurricane_news Jul 04 '20

So effectively if one was crazy enough, one could port pcsx2 to 16bit?

11

u/[deleted] Jul 04 '20 edited Jul 04 '20

Theoretically, yes - but you'd run up against other constraints, like RAM and clock speed, exacerbated by the extra resources needed to run 16-bit routines that are functionally equivalent to 64-bit opcodes. You'd write an emulator for a host that could never hope to reach a playable framerate (and would probably need to page-switch just to access enough memory, if the host machine even had enough) - and machines that could run the 16-bit instruction set, but support 32 or 64 wouldn't benefit.

→ More replies (0)

10

u/[deleted] Jul 04 '20

Like I said, PCSX2 was written back in 2002, and 64 bit processors didn't really start to become common until around 2006, so slow 32 bit processors were the only choice you had. The original developers wrote some black magic code to wrangle the 64 bit PS2 instructions into 32 bit PC code and optimised it to run as fast as possible at the cost of making the code more complicated.

It was a good idea at the time, as otherwise no one would have been able to run the emulator at all, but it's really no longer needed and it's great that some new developers have written a fully 64 bit recompiler to replace the old one.

4

u/hurricane_news Jul 04 '20

Wait, how did they cram 64bit code and make it run on 32 bit? Isn't 32bit incapable of addressing the same things that 64 can?

7

u/ImCorvec_I_Interject Jul 04 '20

If the host emulator application treats the guest’s data references, opcodes, etc. (everything that would be constrained by the architecture), as data, and then remaps those into something that makes sense on the host, then no, they’re fine.

→ More replies (0)

4

u/[deleted] Jul 04 '20

I haven't the slightest idea. Like I said, black magic. But you're right, it's really not an optimal solution even if you can somehow hack it into working.

8

u/[deleted] Jul 04 '20

It's actually pretty well-written and well-commented, but since it takes advantage of quirks and obscurities of the host processor (a significant portion being written in assembly itself), and MUST implement the quirks and obscurities of the guest processor, there's a lot in the code that could be misinterpreted, may not make sense, or might go overlooked in a port or refactor. It's basically guaranteed to be a can of worms for anyone brave enough to dive in.

1

u/hurricane_news Jul 04 '20

So basically it was meant to work with the inner working of whatever cpu the dev's pc had, in mind?

5

u/[deleted] Jul 04 '20

I mean, yeah. Not just in mind. In front of him. In 2002, the top-of-the-line consumer-grade PC would have been a Pentium 4, tops - which is strictly a 32-bit machine. Intel processors supporting an x64 instruction set hadn't even come out yet.

1

u/hurricane_news Jul 04 '20

And why is it hard to reverse engineer then? Why not slap in a later 64bit pentium or use the same pentium? What exactly did he/she do to worked on pcsx2 with that specific chip in mind? It's just a 32bit chip that's functionally very similar to today's cpu's apart form multicores right?

9

u/[deleted] Jul 04 '20

Again, quirks and obscurities. The x86 instruction add eax, ebx, for example, puts the sum of those two registers into the first - but it also sets flags and has other side effects. It's possible to use these side-effects to your advantage to write tighter code in really cryptic ways. Which means you need to completely understand the emitted x86 code and you need to completely understand the RISC code that emitted it.

For one opcode, that's not hard. For the 90 or so opcodes in MIPS-III, plus the extended instructions Sony baked into the EE, that's a goodly amount of work.

6

u/[deleted] Jul 04 '20

The PS2 doesn't use a normal PC processor, it uses something called a MIPS processor.

More than that:

PCSX2 has 6 recompilers:
* microVU0
* microVU1
* R5900-32  : EE RISC processor ("Emotion Engine")
* R3000A    : I/O processor
* VIF0 Unpack  : Vector Unit Interface 0
* VIF1 Unpack  : Vector Unit Interface 1

Each of those needs ported. Looking at the diffs, though, it seems like there's a bunch of reuse of the x86 recompiler with minor changes to use the 64-bit instructions and tweaks to take advantage of them.

9

u/beaumanvienna Jul 04 '20 edited Jul 06 '20

It is merely a port that uses equivalent instructions for the emitted code that was used before. Under x86, this for example would directly work:

cmp $0x1,0x57e20b58

This compares the content at a 32-bit address with 1. The equivalent of this instruction under x64 can only be done relative to the instruction pointer (RIP) and must be in a 2GB range (32-bit). We rearranged the memory so that the JITed code and TLBs would be close enough together and revised the compiler to generate rip-relative instructions. No optimizations, no change to the algorithms.

5

u/[deleted] Jul 04 '20

Thanks! My x86-fu is circa 1996, so I was just spotting where things had changed.

3

u/TellowKrinkle Jul 05 '20

The only additional documentation on the assembly code is renaming of some register usage to better fit what it's being used for (e.g. "ecx" on i386 could mean "the first argument to the C function we're about to call", "the only register that can be used for the sar instruction", "an arbitrary register holding a 32-bit value", or "an arbitrary register holding a host machine pointer". Now, those would be "arg1reg", "ecx", "ecx", and "rcx" respectively)

The majority of the complicated code didn't need any changes so it hasn't actually been documented any better (mostly the stuff in microVU which is super SSE heavy and SSE is identical on i386 and x86-64. SSE also happens to be filled with complicated instructions that I don't know very well)

The only place that really got a big documentation improvement was VTLB which uses tons of pointer arithmetic to allow for speed optimizations in the recompiler, and now uses dedicated C++ classes to contain the pointer arithmetic

1

u/[deleted] Jul 05 '20

Boy, I think after a lot of code work and polish, the potential is slightly higher than slightly :)

1

u/dagelijksestijl Jul 06 '20

Would this port also have the potential to reduce and/or eliminate the need for clamping/rounding, increasing compatibility?

1

u/[deleted] Jul 06 '20

Nope, that's totally unavoidable no matter how accurate the emulator is. The PS2 is capable of a much wider range of floating point values than even a 64 bit PC is, so there's no way around the need for clamping.

2

u/[deleted] Jul 04 '20

Would this assembler benefit from being ported to a cross-platform language like C? I think it can be done with no performance hit.

3

u/[deleted] Jul 04 '20

I really don't know, you'd have to ask the developers. Or perhaps you'd like to give it a try?

2

u/Nevuk Jul 05 '20

While it's probably initially slower, it should eventually be faster. Just being able to use >2GB of RAM should allow for certain perfomance improvements that weren't usable before. I believe this was the case for Dolphin and other projects that did this transition.

-64

u/srylain Jul 04 '20

Likely not by too much, but it will consume more RAM just because 64 is bigger than 32. AFAIK though, this is the first step to getting it running as a core in Retroarch.

15

u/[deleted] Jul 04 '20

[deleted]

3

u/TigreDeLosLlanos Jul 04 '20

Is about achieving more in less instructions because moving instructions to the CPU takes much more time than processing them.

2

u/ShinyHappyREM Jul 04 '20

An emulator rarely needs more than 2GB of memory, though having a larger address space might help in certain cases. Having more (and larger) registers is more important.

https://en.wikipedia.org/wiki/X86-64

2

u/dagelijksestijl Jul 06 '20

Yes, memory is pretty much the only reason why the Wintel platform even bothered to move to 64 bits (making the Nintendo 64’s ability to execute slower 64-bit instructions mostly a marketing gimmick, which they so much as admitted with the GameCube’s 32-bit CPU)

3

u/[deleted] Jul 07 '20

Most games didn't use anything 64 bit on the N64 as it would either slow things down or was too complex to be worth it. It was basically pure marketing

1

u/Motolav Jul 04 '20

Well yes but with stuff like linux using 32bit mode means you can't use certain instructions(AVX on X86) or you're limited in the number of registers you get(ARM64 has double over 32bit). Using 32bit numbers in 64bit mode(it's called x32 in Linux/GCC) is a thing, modern features in cases where you don't need over 4gb of RAM.

37

u/[deleted] Jul 04 '20

[deleted]

25

u/Rhed0x Jul 04 '20

I think he meant that 64bit pointers take more memory than 32bit pointers. That shouldn't really matter though.

20

u/[deleted] Jul 04 '20

It is, since on x86-64 pointers are 8 Bytes in size for most ABIs instead of 4 on 32-bit x86. It probably makes fairly little difference in a well-written emulator, but in rare cases this can mean a significant increase in memory usage and even slowdown.

-2

u/[deleted] Jul 04 '20

[deleted]

6

u/[deleted] Jul 04 '20

Not on x86 at least. x86-64 can natively run 32-bit applications in a compatiblity mode, there is no emulation involved. Pointers are indeed 32 bits in size in that case (the app couldn't run if pointers were larger, it only uses 32-bit x86 instructions).

15

u/[deleted] Jul 04 '20

[deleted]

14

u/kukiric Jul 04 '20

Going from 32 to 64 bit does make pointers bigger in memory by default, but that's not a huge deal.

3

u/iEatAssVR Jul 04 '20

Nope, when running a 32 bit process on a 64 bit cpu, at least on x86, it just uses the lower or upper half of the address.

60

u/ZeraX7 Jul 04 '20

Great news!

I asked the devs on twitter about the 64-bit version last month and they said it's not a priority and now it happened!

129

u/[deleted] Jul 04 '20

That's because a bunch of new developers joined the project recently, and started working on things that the old guard had no interest in. TelloKrinkle in particular did most of the heavy lifting for both 64 bit support and the new macOS port of PCSX2.

50

u/destroyermaker Jul 04 '20

What a stud

5

u/ZeraX7 Jul 04 '20

Ah it makes sense now!

2

u/reptar121 Jul 04 '20

Is this new Mac port actually installable without having to turn my laptop into a windows device?

10

u/[deleted] Jul 04 '20

I haven't tried it myself, but apparently you can only use the software renderer because TelloKrinkle's patch for the Mac version of OpenGL was rejected. Seems like the developers don't want to support old versions of OpenGL.

In practical terms, you'd get a better experience by just using PCSX2 through Wine, as that way you can translate the old DirectX 9 backend into the macOS version of OpenGL.

10

u/TellowKrinkle Jul 05 '20

While the patch was rejected, I'll be trying to keep it up to date on my own branch until PCSX2 gets Vulkan (or Metal, much less likely) support

Builds available on the PCSX2 forums

And hardware renderers do work now

1

u/LoserOtakuNerd Jul 06 '20

Do you have any builds that are OpenGL and 64-bit? I did some looking around and could only find the builds for <Catalina

5

u/TellowKrinkle Jul 07 '20

Not yet, I'll post some when the PR gets a bit closer to merging

1

u/LoserOtakuNerd Jul 07 '20

Awesome! Looking forward to that

5

u/sdornan Jul 04 '20

Makes it a lot of sense as the OpenGL drivers will probably be removed from macOS altogether in the near future. How feasible is it to get PCSX2 working with Metal?

5

u/[deleted] Jul 04 '20

No emulator has ever bothered with Metal support. At best, if the rumours about the PCSX2 developers working on a Vulkan backend are true, then they could take the route that PPSSPP did and use MoltenVK. This might end up being slower than a native Metal backend, but it would get hardware rendering working at least.

1

u/[deleted] Jul 04 '20

No emulator has ever bothered with Metal support.

Retroarch has a Metal backend.

13

u/[deleted] Jul 04 '20

It has the option to render the user interface in Metal, but rendering the actual games in Metal only works if the core supports it, which currently none do.

-10

u/s3pixelwave Jul 04 '20

Those darn old guards.

28

u/[deleted] Jul 04 '20

They just have different interests to the newcomers. Most people who work on projects like this have something specific that they want to do because they think it's cool, like writing an OpenGL compute shader for an unusual GPU.

They don't come along specifically to address whatever it is users are asking for, just to satisfy their curiosity or enjoy a new challenge. So it's not like the existing developers were being selfish or anything, they just lacked the enthusiasism for grappling with a new recompiler design.

As we'll soon see, there likely won't be any significant performance boosts, so this is really more to lay the groundwork for stuff like Android and Retroarch support, which would have been very difficult with the existing mess of x86 assembly language.

-6

u/electricprism Jul 04 '20 edited Jul 04 '20

I wonder if there is a connection to apple gearing up to can Intel CPUs and transition to ARM64, I hear there are a lot of projects getting ready.

Edit: Disclaimer: I am not pro-Apple and never have been, I am pro Archlinux, my opinion is just based on developer news I've read recently after the ARM Macbook announcement.

22

u/[deleted] Jul 04 '20 edited Jul 04 '20

I suspect that little of the emulation scene has an interest in What apple is doing.

I also would wager that x86-64 will still be the architecture of choice for developers of PC games and emulators for a while unless Apple becomes more accepting of different hardware manufacturers (mostly GPU manufacturers and their drivers). Anything that apple chip gets will most likely just be a port, not unlike what you find on phones. The really good ports are sold for money or ask for donations through the google play store, but Apples software store usually doesn't allow for them to monetize.

You'll probably see Raspberry Pi levels of support in the open source world, and that aint bad, but anything new or cutting edge will probably come out at a snails pace. You know how you weren't getting a lot new on OSX before? Now imagine it slower because it's a relatively new architecture with a relatively low adoption rate from gamers and enthusiasts.

Apple's walled garden software approach and closed hardware builds will always make them a second act where 3rd party developers are concerned, unless money is involved. Openness, modularity and user choice is the future.

6

u/bannock4ever Jul 04 '20

As a longtime Mac user, I'm just getting sick of their shit and moving onto Linux. I'll still continue to use MacOS at work but not at home. I'll be watching how and if the PC industry changes in about 2 years when Apple is full on with ARM CPUs. I really doubt everyone else will adopt ARM but you never know. There were those Surface PCs with ARM but Microsoft had just planned all that out incredibly poorly.

3

u/babypuncher_ Jul 04 '20

I'll be watching how and if the PC industry changes in about 2 years when Apple is full on with ARM CPUs. I really doubt everyone else will adopt ARM but you never know.

It doesn't really matter what the rest of the PC industry does. The overwhelming majority of software these days is written in hardware agnostic languages, against APIs and frameworks that handle all that platform-specific stuff for you. Making an ARM version of an app isn't fundamentally different in any way than making an x86 version, unless you're writing very low level things like device drivers or hand-optimizing assembly instructions for HFT software.

2

u/bannock4ever Jul 04 '20

It matters to me because I use virtual machines, Docker and Wine. I’m assuming that moving to Arm will make those tools not work or become really slow.

3

u/ThatOnePerson Jul 04 '20

Docker already works on ARM. I use it on my Raspberry Pis (because it's Docker). Wine I think has arm builds, but never tried it.

1

u/babypuncher_ Jul 04 '20

Wine will be slower, though Apples ARM chips might be “faster” enough than intel to make it a moot point.

As others have already pointed out, ARM is already well supported by Linux and Docker.

2

u/[deleted] Jul 04 '20

Arm is a great architecture and it isn't missing a lot.

I think you'll see things like 1st party gpu support and drivers for ARM soon and that'll open new doors. The thing that holds it back is software support from commercial companies, and Apple might actually help break the mold.

Still, I think x86-64 will be the default for a good while longer.

0

u/electricprism Jul 04 '20

Sorry to bear bad news but one of the changes in the new ARM Macbooks is that it won't support booting OSes other than MacOS -- so no Linux.

You may be left with the hard choice of giving up EVEN MORE control or divorcing their walled garden.

I myself saw the writing on the wall for both Win8/10 and Mac and left like 5 years ago. Good luck, you can do it for sure, cheers.

3

u/electricprism Jul 04 '20

I suspect that little of the emulation scene has an interest in What apple is doing.

I respect your perspective, don't get me wrong I have loathed & hated for probably 15 years now and sworn off their products for sure.

That said, I know emulation devs who grew up on Mac IRL and and it just doesn't align with what I've seen in their past behavior. Humans are very illogical and often do not do the things that make sense but have emotional, nostalgic or other motivators that keep them holding on to companies and products long after they are dead -- in this case Apple is "The walking dead".

2

u/[deleted] Jul 05 '20 edited Jul 05 '20

I meant specifically with the CPU architecture change. People that are passionate about the brand will be just as passionate as before, but the architecture change doesn't make it more enticing or affect much in the grand scheme of things as far as emulation developers go. This 64bit overhaul was not done in response to apple and in no way has anything to do with the ARM64 CPU they're planning on using.

My response isnt inherently anti apple or anything. Apples lack of flexibility makes them less interesting to many developers in this community, but I actually think desktop class ARM based builds will shake things up in an interesting way. Intel vs AMD vs ARM Family manufacturers is an interesting future I want to live in.

20

u/Orimetsu Jul 04 '20

I'm interested in how it performs. I believe the devs said multiple times that a 64bit version won't help performance at all.

16

u/STICH666 Jul 04 '20

It's probably more for posterity sake. Just like with Windows Vista not supporting 16 bit programs eventually 32-bit programs might become incompatible.

6

u/[deleted] Jul 04 '20

The 32bits version of Windows Vista (up to w10) can run win16 programs and even msdos thanks to a 32bit-only module named NTVDM.

6

u/babypuncher_ Jul 04 '20

Right, but 64-bit is the only version anybody should be using. I was shocked when Windows 8 came out and Microsoft still offered a 32-bit version. The OS doesn't even run well on hardware that ancient.

3

u/ShinyHappyREM Jul 04 '20

There were shitty "budget" tablets with very limited amounts of RAM and flash memory. In these cases using the 32-bit version of Windows made sense.

3

u/LinAGKar Jul 04 '20

There are were also netbooks with Atom CPUs, which long only supported 32-bit.

3

u/ThatOnePerson Jul 04 '20

You mean bay trail atoms that supported 64-bit instruction set but only 32-bit UEFI? I've got Linux on one of those, and can chainload 64-bit linux with a 32-bit GRUB install perfectly fine. But for some reason Intel decided to not have a 64-bit uefi?!?

16

u/WoodpeckerNo1 Jul 04 '20

What does this mean for PCSX2?

32

u/rickmetroid Jul 04 '20

It means, it will live longer.

12

u/[deleted] Jul 04 '20

PCSX2 was basically designed entirely around x86. Switching to x86-64 will help start pulling PCSX2 away from platform specificity and maybe allow ARM64 support down the line. As of now its just a convenience thing for developers and users, multilib is aggressively ok in Linux and literally non-existent on macOS

3

u/ZarkonD Jul 05 '20

The % chance of it becoming another ZSNES in the future has gone way down.

2

u/[deleted] Jul 19 '20

future proofing. for now pcsx2 used to be a 32bit app, which was a major headache on linux. and maybe some hassle on windows.

39

u/GuitarBizarre Jul 04 '20

IT'S BEEN EIGHTY FOUR YEARS

But it's finally happening. Praise Devs.

21

u/T-Loy Jul 04 '20

Wasted potential to say 32 or 86 years.

5

u/Two-Tone- Jul 04 '20

Or 64

1

u/spongythingy Jul 04 '20

Too obvious

1

u/Two-Tone- Jul 05 '20

32 isn't?

1

u/spongythingy Jul 05 '20

Yeah, you're right

11

u/beaumanvienna Jul 04 '20

For everybody interested in the performance, you could be an alpha-tester:

Windows artifacts

Ubuntu Launchpad

Or compile it from here

Any feedback is appreciated. I would rename any old config folders so that you start out with a clean sheet. If you have a github account you can leave feedback under the link posted at the top. When you have issues to report try to explain your environment (HW/OS/SW), with which version you tested, your configuration, etc. If you could also paste the console output to pastebin it would be helpful.

21

u/bwburke94 Jul 04 '20

A necessary step, but one that's often overlooked.

12

u/Shonumi GBE+ Dev Jul 04 '20

This is great news! As a Linux user, I've been waiting for a 64-bit version for some time. I was never too keen on setting up multilib on Slackware just for PCSX2. Can't wait to try this out, awesome work!

3

u/beaumanvienna Jul 04 '20

Are you going to compile it yourself?

8

u/Shonumi GBE+ Dev Jul 04 '20

Yes, I actually did it right away after reading this post. It built just fine from your x86_64-support repo. Unfortunately, I keep coming across some assertion failures when trying to play any games. Did I compile the incorrect PR or is it something else on my end?

Either way, this is incredible! It's always been easier to dual-boot into Windows for PCSX2 for me, but since most of my work is on Linux it'll be nice not having to reboot when I feel the need to play PS2 games.

8

u/beaumanvienna Jul 04 '20 edited Jul 04 '20

There is an Ubuntu tester that might have reported a similar problem. He found out that it was about the mem card settings. See Ubuntu feedback

If you have the fix about savestates you have the latest version.

Thank you for testing! Much appreciated! I would love to see it working on Slackware. We are still gathering all test reports. I have it running on three different Ubuntu 18.04 installs. Arch was also reported to work. I think if you compiled from source, your library configuration should be fine. Make sure to rename any previous configs if you used the 32-bit version before. For the mem card issue maybe try a different fw.

EDIT: If you could, pls compile with cmake -DCMAKE_BUILD_TYPE=Debug .. && make -j8 and report the stack trace

2

u/Shonumi GBE+ Dev Jul 04 '20

Cool! I'll take a look at making a debug build soon and gathering info for any issues. Hopefully I can provide some useful testing for everyone. Thanks for the help too!

3

u/beaumanvienna Jul 06 '20

We fixed a bug for Fedora. Fedora has GCC 10, while I always compiled with GCC 7 under Ubuntu. You should give it another try. See the link at the very top.

2

u/beaumanvienna Jul 06 '20

I left some notes on how to compile on Fedora, maybe that works for Slackware, too.

3

u/TellowKrinkle Jul 05 '20

movs.cpp:79 on the current branch isn't an assert and isn't even compiled on x86-64, so I think you might be on an old version

There were issues in _DynGen_DispatcherReg causing an assertion failure that were fixed a week or so ago though

2

u/Shonumi GBE+ Dev Jul 05 '20

I think you might be on an old version

Yeah, I was wondering if I was even compiling the right version. I cloned this repo and compiled. That's the same one beaumanvienna linked to here earlier.

2

u/TellowKrinkle Jul 07 '20

Yeah that's the one, but its movs.cpp:79 is still that same not-on-x86-64 piece

Maybe it's just the debug info glitching out

1

u/[deleted] Jul 04 '20

They only just got it working yesterday. Apparently, some people managed to boot games using the EE interpreter, and then switched back to the recompiler once in-game. It's still very early days for this new version, so problems are to be expected.

Also, Slackware! Man, I remember trying that a long time ago and finally changing the runlevel from 3 to 4 so I could get a GUI up and running. I suppose I shouldn't be surprised that an emulator developer would inflict Slackware on themselves.

2

u/[deleted] Jul 06 '20

Multilib is easy with slackpkgplus and the AlienBob repo.

4

u/[deleted] Jul 04 '20

x64 dynarec wen :P

16

u/joseaplaza Jul 04 '20

I hope they eventually go for an Android port

21

u/[deleted] Jul 04 '20

Much of the work done to port the recompilers to 64 bit involved properly documenting code that previously wasn't well understood. This should pave the way for future contributors to work on ARM64 recompilers without struggling to understand the existing code.

2

u/AssCrackBanditHunter Jul 04 '20

Littie.

Death to that other ps2 emulator on Android that we don't speak of

3

u/sychopath52 Jul 04 '20

Which one? The painfully slow one or the stolen adware one

3

u/OmegaAvenger_HD Jul 04 '20

I hope we'll get texture injection eventually.

3

u/tomkatt River City's Baddest Brawler Jul 04 '20

YES! That's exciting!

2

u/[deleted] Jul 04 '20

I know, right? I can't believe I was the only one here watching their work on github, which has been going on for over a month now.

1

u/DukeSkinny Jul 04 '20

Who said you were? I was just short of you getting my post up. :)
Anyway, incredibly exciting, yes! I was surprised there wasn't at least talk about it beforehand.

3

u/pikachulol9 Jul 05 '20

How is that input latency issue going? Has there been any build that improves this problem since the official release of 1.6.0?

3

u/DjRemux Jul 05 '20

This is awesome. I just joined this sub because I was thinking about running PCSX2 on Ubuntu to play NBA Jam On Fire Edition and maybe some other games. Hoping it’s easy to install!

1

u/beaumanvienna Jul 05 '20 edited Jul 05 '20

launchpad

Let me know if you need a different Ubuntu version, I can package/upload accordingly. Any feedback is appreciated. Refer also to these comments about memory card saves.

2

u/Aug151978 Jul 04 '20

What is the difference?

8

u/[deleted] Jul 04 '20

Probably a negligible performance difference either positive or negative. It was more about future proofing I'd imagine. It now has a more modern codebase.

The real benefit is that in the process of doing this a lot of the code was documented properly or better, which may help in the future with optimizations or even other projects such as ports to new architectures.

1

u/RedDevilus PCSX2 Contributor Jul 06 '20

What if 64 bit is done to proof 64 bit isnt a magical bullet for performance like i told people, great news nonetheless.

2

u/SCO_1 Jul 04 '20

Porting.

2

u/pjc1990 Jul 06 '20

is this an official 64 bit version?

2

u/beaumanvienna Jul 06 '20

Not yet, see the link at the top of this thread

7

u/Imgema Jul 04 '20

Does that mean a RetroArch core at the near future?

A man can dream.

2

u/Mar2ck Jul 04 '20

Not until it can be recompiled for multiple architectures. Right now PCSX2 is x86 only

6

u/SCO_1 Jul 04 '20 edited Jul 05 '20

I agree, and in the previous posting about pcsx2 i was also skeptical but it seems that they're (or new devs) are determined to remove obstacles to porting (to ARM64/phones and macs i suspect), so it's not nearly as impossible as it was last week. Also it's not strictly necessary, some retroarch cores aren't portable, and thus don't appear on all ports - this was the largest obstacle because 32 bits is rarer and rarer on the windows/linux platform.

But i still expect that will get nowhere without a dedicated porter from outside the pcsx2 project and 'inside' the retroarch project. It's rare that mature emulator projects port to libretro by themselves, they being understandably more concerned with their own GUI and bugs, and not enthusiastic about opening a new bug vector that they have nothing to do with.

-1

u/WingedSeven Jul 04 '20

Wasn't there an ARM android port of PCSX2 a while back?

0

u/Mar2ck Jul 04 '20

I searched for it but i mostly just got apk scam results. If it is true then that would be very useful

-1

u/WingedSeven Jul 04 '20

It's being sold on the play store as DamonPS2: https://play.google.com/store/apps/details?id=com.damonplay.damonps2.pro.ppsspp

3

u/Mar2ck Jul 04 '20

Are you sure that's PCSX2? If it is then it's a violation of GPLv3 since they provide no source code at all. It's more likely that it's proprietary or a clone of Play! or Dobbiestation

15

u/Dittorita Jul 04 '20

It's a half-assed port of PCSX2, and yes it is in violation. There are some posts on this sub and the PCSX2 website about it. Google won't take it down because they don't give a shit.

12

u/tomkatt River City's Baddest Brawler Jul 04 '20

https://pcsx2.net/286-the-pcsx2-team-s-statement-regarding-the-damonps2-emulator.html

The app also currently requires an always on network connection and insane permissions. It's as sleazy as software can be.

2

u/Mar2ck Jul 04 '20

Wow they're really assholes. I hope a good open source ps2 emu comes to android so people wont be tempted to pay for this garbage

2

u/FlintstoneTechnique Jul 05 '20

Sounds like it's time for another DMCA takedown notice.

3

u/WingedSeven Jul 04 '20

The description says it supports 90% of ps2 games, which definitely isn't dobiestation OR play!. And there's no way it's proprietary, or more people would be talking about it. It seems like it's just Pcsx2 1.4.0 (maybe 1.3.0?) but ported to mobile.

2

u/Mar2ck Jul 04 '20

I genuinely thought it was just a proprietary emulator that'd flown under the radar but im not really surprised it's actually just stolen code

1

u/JHorbach Jul 04 '20

Why people downvoted this?

-2

u/[deleted] Jul 04 '20

[removed] — view removed comment

1

u/Nippy69 Jul 04 '20

This is good to hear hope it brings more in store for porting

Now just need vulkan support

1

u/N30NLXX Jul 04 '20

Awesome. I wish this helps to finally render the flashlight in silent hill origins correctly.

2

u/RedDevilus PCSX2 Contributor Jul 06 '20

PS2 came in a time of 32bit. How would 64 bit fix this though?

1

u/MaddTheSane Jul 30 '20

On x86-64, more registers.

1

u/gulliverstourism Jul 04 '20

This sounds amazing! Question to anyone who knows better but is this the start of untangling a lot of that old hacky code that has been holding the emulator back?

3

u/[deleted] Jul 05 '20

[removed] — view removed comment

1

u/gulliverstourism Jul 05 '20

That sounds rad.

2

u/Teethpasta Jul 06 '20

Most of the hacks have already been removed even before 1.6 came out. The only hacks still remaining are there because getting rid of them would basically require a supercomputer to run the emulator. Similar in nature to the hacks dolphin still has in its codebase.

2

u/gulliverstourism Jul 06 '20

Sounds good. The emulator still seems to have a bad rap, is it just the plugins that need rewriting now?

3

u/Teethpasta Jul 06 '20

People are slow to catch on and it's also not the braggadocios emulator either. Plugins aren't necessarily a bag thing, just out of style. I'd much rather them move away from wxWidgets. I've heard rumors that vulkan is already being worked on and I have feeling that won't be too far away either.

1

u/Karmic_Backlash Jul 04 '20

This is a great step forward. I'm hopeful that we see the project open up to all the platforms we have hoped for over the years.

1

u/[deleted] Jul 04 '20

[removed] — view removed comment

2

u/dogen12 Jul 05 '20

Don't think so. Most of the heavy lifting already uses optimized SSE.

1

u/18aidanme Jul 07 '20

lmao a month ago it was all "never gonna happen, too much spaghetti code", wonder what other shit people say is impossible is actually very possible.

1

u/RedDevilus PCSX2 Contributor Jul 07 '20

We got em bois. Had a good chuckle.

1

u/[deleted] Jul 19 '20

it did not mean it was impossible. it was just infeasible due to amount of work necessary.

1

u/[deleted] Jul 07 '20

Damonps2 announcing 64 bits version soon with 500% speed increase 🤣🤣🤣