Add Support For ARM Platforms #2915
Comments
|
@Askmewho Have you ever written a recompiler? Would you like to retarget the existing one? Sorry, let me rephrase that. Have you ever written several independent recompilers? Would you like to retarget all of them? It's really not as simple as you make it sound. At all. |
|
@pixelherodev I don't understand this defense mechanism of acting like the most benign of suggestions are like some personal attack against the emulator. Yes, writing a JIT is hard. He also didn't imply otherwise so I don't understand your reaction. @Askmewho to answer your question. We don't have plans for an ARM port at this time. Current focus is release of 1.6.0 and bug fixes. Perhaps a smart person or persons will start a branch to port but as of now I'm not aware of anyone who has the time, motivation, or know-how to do so (at least not all 3). |
|
thanks @tadanokojin for the answer. @pixelherodev I am sorry if you take my comment as an offensive one. It was never my intention. |
|
Sorry if that's how it came across, didn't mean it to sound that way either. I wanted to make sure you realized this wasn't entirely a matter of there not being interest in the idea. I may have misinterpreted your statement that Even if the entirety of the dev team started focusing on it right now, it would still take a large chunk of time. |
|
Lack of people to write a recompiler for either arm or a x64 version is the biggest problem, too. Different people have different skillsets, and the majority of the people that worked on the recompilers in the part are no longer involved with the project, or simply don't have time to work on them. That's one reason why even the entirety of the dev team focussing on it wouldn't really help much. Also, this is an older project with a large codebase and a lot of legacy code. It's simply more interesting to work on something from scratch or a newer project that still has a lot of sections that aren't done. If someone was interested in writing a recompiler, they'd be rather more likely to head over to Dobiestation, or something similar. For me, personally, it's more productive to work on other areas of the code, because there I've got a better idea of what I'm doing, whereas with a recompiler, I know vaguely how it works, but not enough to even start on working on one. Mind you, if someone drops by that knows how to do it, starts writing one and makes some prs, we'd certainly be checking those out... |
|
sorry, its not my native language. and I understand if you wont to put the huge effort needed. you all do this for passion. and the emulator just runs great on x86, why bother to port it on arm? it has no sense, and I understand that. Ive only want to transmit the huge necessity of an arm port of these emulator because the arm community not only see on arm a great linux platform today, they see (like I) the future of linux as desktop, because openness, or just because its cheaper and less controlled by huge corporations, just like risc-v its the next thing behind arm. maybe you don't like linux and I am taking the wrong way here hahahahah thanks as always. |
I'd love to see it ported to as many platforms as possible. Regardless of how it runs on x86. I feel most the team shares this sentiment.
Trust me, we understand there is a large desire for an ARM port and I certainly would love to see that. But as arcum said, I don't develop dynarecs and most of the team doesn't. Emulators are complicated and we all specialize in some part of the development. Unfortunately, there's no one who specializes in that at our disposal now. |
|
Basically, you can be as passionate as you want about designing computer circuitry, but if what your team is good at is building furniture, you're best off putting your efforts there. |
|
Hmm... I haven't done one this complex, but I do actually specialize in CPU emulation. It's basically what I've spent the last two or three years on. I've done a few small dynarecs, though they were all variants of 8-bit CPUs, so this I'm going to take a break from my other project and see if I can get even just the beginnings of a x86_64 port done at least. I can't really focus on ARM, as I have no - wait nope I take that back. I have a Raspberry Pi at my disposal. I'll see what I can do tomorrow, not going to look for my HDMI cord at this hour. If someone can find links to the manuals for the relevant instruction sets, that would be a massive help. I'm also not entirely up to speed on the PS2 architecture, so it'll likely be at least a few days before I even get started on the actual work, because I prefer to take the time to understand what it is I need to do before I try to do anything. |
|
Where as I started as the one that was keeping the Linux side of things afloat and doing code cleanups occasionally. When it was half Windows, half gtk, I was doing the gtk bits, but then wxwidgets replaced a lot of it, aside from most of the plugins... If you take a look at what's already in there, I seem to recall gregory said he'd started putting in some x64 instructions in there at some point. If you delve back many years before the recompiler was rewritten, there was a basic x64 recompiler a long time ago that got scrapped and never really got too far, too. This may help, too: I expect if you catch greg around, he could point you in the right direction... |
|
decompile daemonps2 JIT, they dont deserve it!!! hahaha (just a joke) |
Funny you say this: I did decompile the APK and it doesn't have its own JIT. It uses a generic x86>ARM JIT on top of PCSX2's dynarec. So it is double JIT-ing the game. Part of why it runs so poorly. |
|
Wow that is horrendous!! Very good info!! |
|
I will scout some jit devs for the task. |
|
I'm going to see about doing this for x64, but ARM is out for me, sorry. |
|
The trick is, for an AMD64 dynarec we already know the core and plugins work. For ARM, we have no idea. Before you dive into designing a dynarec, make sure it at least runs on the interpreters for that architecture first. |
|
There's already emulator working on Android and if you want to contribute go to there discord server |
|
they doesnt look than they use an arm JIT at all... maybe its for x86 android. |
|
What doesn't have an OpenGL backend? |
|
He's referring to DobieStation |
|
@pixelherodev pcsx2\x86 is where a lot of other things to look at. BaseBlock.cpp/h, everything in the ix86-32 folder, and most of the rest of the x86 folder too, really.(The stuff there should really be organized in a couple folders and isn't.) You'll notice the define _M_X86_64 around a bunch too, and some of the spots are clearly more to mark where x64 code goes. GSdx also has JIT, but that uses xybak as an emitter, and work's already been done on the x64 side there, IIRC.. |
|
FTR Dobie doesn't have an Android port at this time. Neither does it have a video backend. Dobie is in the early stages of development right now. For Android/OpenGL you'd be thinking of Play!. Not very familiar with the project myself so I won't speak on their behalf. @Askmewho Can I please ask that you refrain from spamming. Edit your comment instead. Thanks. |
|
Actualy, Play! on Android is a strip down version of the desktop one as of today. It is much slower, misses some GS effects due to GLES 3.0 vs desktop OpenGL and have a lower compat (missing DVD9 support for exemple). But the major problem (which can be an advantage depending the point of view) is it's HLE oriented emulation. I am sure if it become LLE, it can be much, much faster than it is right now. The ARM based machines and Android are just not suited for PS2 emulation, even the Athlon 200GE (a 50 bucks CPU with vega 3 inside) bump up the Play! framerate to 60fps in some games (and handle Ratchet at nearly full speed with some trick on PCSX2). |
|
@tadanokojin sorry. Ive deleted the comments. I will try play again, but if it doesnt have full opngl targert it should be a missed oportunity. On rpi3 and rpi4 we have full opengl profile, 2.1 and 3.0(at least) respectively. I dont get why ps2 its so hard to emulate in comparison eith psp, not far on specs and being mips too. But maybe you know a lot more about that |
|
Hi everyone, i just was thinking about how awesome could be to run PCSX2 on Arch Linux ARM, (i'm thinking about buying a RasPi 4 in the near future), but it's been a little disappointment to read that there's lack of people who dominates or knows about ARM. Such a pity :(. I just wanted to give thanks for the great work. Bests ^^. |
|
Your only option for the foreseeable future and beyond would be this Though, considering it's only just now ~5W x86 cpus are getting near a very satisfactory experience.. I cannot see anything below an SM8250 even getting past boot. |
|
Yeah, we are even thinking to give a shot on pcsx2 under box86. It will be a horrible approach like daemonps2 does, but at least its open source haha. I mean, double emulation its the horrible approach. Box86 may have a. Efficiency of 25% , which is not bad. Whatever, hope we can launch some games. Play emulator sucks |
|
@arcum42 Thanks for the directions, I'm taking another look now. I can't make any promises, but I'm going to look into porting to x64 (because I need to get back into practice with dynamic recompilation for a different project of mine and this seems like a good way to do that). |
|
@pixelherodev No problem, it'd be great to see someone working on it. I can tell you that in the x86 folder, iCore.cpp and ix86-32/iCore-32.cpp are where the register allocation for x86 and xmm are located, as I'd been looking around at that code. Otherwise, a lot of files in there are obviously instructions for certain chips. That lone assembly file is just for supervu, and some things in there are complicated by having both supervu and microvu coexisting, honestly... |
|
What would be a good place for general discussion towards this? Is the IRC channel active? Should I open an issue for discussion? |
|
Generally speaking, I think the pcsx2 discord group is where a fair amount of discussion happens, and the dobiestation one may be worth going in as well, since that's where the most active discussion of developing a ps2 jit tends to happen, even if it's not for pcsx2. (there's a lot of overlap between the two discords.) Pcsx2: https://discord.gg/Pc6UHa |
|
I'm honestly looking forward to proper 64bit recompilers, it would be neat if this would make a speed difference, especially for low power mobile CPUs like Core-M. |
|
Could you just answer that guy instead of just sending emoji reactions? We know you don't have the devs.. but being a bit more polite it's free.. |
|
Core M is x86, and as stated countless of times a 64 bit recompiler (or vulkan, or whatever) wouldn't bring any particular advantage. |
|
I know core M it's x86_64! Just the last comments were talking about that. |
|
A 64-bit recompiler will not improve performance on low-power machines. It is entirely possible (and indeed quite likely) it will be slower initially (though eventually it should be able to at least match the x86 recompilers). The only actual immediate gain from 64-bit recompilers is that it modernizes PCSX2 and removes the need to run a chroot / have 32-bit libraries available (which can massively reduce effective disk usage and make life a lot easier). That's it. Nothing more. There's no magic speed improvements, and it'll likely be slower initially and take a while to catch up. |
|
Yeah, I thought that was the main interest. Especially than on the not that far future x86 will completely dropped, and we will had to use VMs to run that programs.. |
|
That's the big reason why we need 64 bits. Linux distributions really want to drop 32 bits. If they hadn't backed down, the 32 bit libraries would have been gone from new versions of Ubuntu not that long ago. I expect that'll still happen eventually, and I could see less and less Linux compatibility if things don't get ported to 64 bits. Installation and development on Linux would be a lot easier if you didn't need to install a bunch of 32 bit libraries as well... |
|
That's only a PITA on debian (like everything else /s). Then it was only ubuntu going bonkers imo. |
|
If they drop it they drop it. Doesn't matter why or if you can comprehend it. We have to adjust accordingly. |
|
Well, Ubuntu is Debian based, and half the distros out there are Ubuntu based... When I was trying to develop for pcsx2 on Mint, which is Ubuntu based, I remember I was having enough trouble cross-compiling that I had to set up a 32 bit chroot to compile in. Then I started running into trouble because the chroot was Ubuntu and couldn't be upgraded past a certain point because Ubuntu no longer had a 32 bit version. Anything using apt-get and multilib is a pain, too. I don't know how many times I was told I couldn't install something 32 bit because the dependencies weren't installed instead of installing them, or asked if I wanted to uninstall 64 bit packages I needed when trying to get the 32 bit ones installed. It's just as well that I moved over to Arch, where multilib and crosscompiling works fine for me. Mint has gone 64-bits only now, too, though still with multilib, last I heard. All in all, I'll be quite happy if pixel can get a 64 bit jit working properly in pcsx2, in any case. |
|
Even if you eliminate Linux from the equation a certain UNIX operating system dropped 32 bits already. |
I suggest getting away from discord and to irc, or a p2p chat |
What is the added benefit of this? PCSX2 has an irc which is still open and nobody uses it. Everyone is on the discord servers. |
So, discord then |
https://sneak.berlin/20200220/discord-is-not-an-acceptable-choice-for-free-software-projects/ Personally discord ensures that several users will be excluded from participating. |
|
Go to our IRC and talk to nobody then. This thread isn't the place for this conversation. |
Hi devs, this emulator has a long time being on top as a ps2 emulator. At this point even older x86 hardware can handle this emulator at great performance. I understand than you are on a sweet spot fixing things here and there, but being arm so cheap platforms, at least you should try to start an armhf or arm64 development branch. The arm community its expecting than you decide to move foward.. And this its taking time. Hope you find the way to rewrite the less possible and as always, thanks the effort.
The text was updated successfully, but these errors were encountered: