Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic recompiler [$895] [BOUNTY] #214

Open
twinaphex opened this issue Aug 8, 2017 · 116 comments

Comments

Projects
None yet
@twinaphex
Copy link
Member

commented Aug 8, 2017

See bounty link here -

https://www.bountysource.com/issues/48048939-dynamic-recompiler

Conditions:

  • A dynarec system for Beetle PSX, preferably written in C or else C++98. Portability to the various targets libretro supports is important in considering the programming language being used here. No C++11 or C++14 please,
  • A working backend for x86 32bit, x64 (x86 64-bit), ARMv7 (32bit). aarch64 (ARM 64bit) is optional and could maybe be made a separate bounty.
  • Should be engineered in such a way that new backend implementations for other architectures (like ARM and PowerPC) can be easily implemented. There is a separate bounty for a PowerPC dynarec, but first this one needs to be successfully completed before the PowerPC dynarec is feasible.
  • The dynarec needs to be PIC-compliant. This is essential since libretro cores predominantly are meant to run as dynamic libraries.
  • Should be signifcantly faster than the interpreter CPU core, and should lower Mednafen/Beetle PSX’s CPU system requirements considerably.

Some things to look at if you might need some inspiration -

https://github.com/daeken/beetle-psx-libretro

Daeken a long time ago started work on a dynarec for Beetle PSX. It technically works, but is too slow to be usable and probably still contains many bugs. We also in hindsight do not want to rely on generic JIT engines like libjit and LLVM, believing them to be too slow for the job at hand, and that we'd rather have just a custom-written dynarec. So look at it for inspiration but don't try to mimick what was done here or make the same design decisions like opting for libjit or other generic JIT engines.

Also - once this bounty has been completed - it would be much easier to make a Wii U dynarec. A separate bounty for this exists here -

libretro/RetroArch#4852

https://www.bountysource.com/issues/44566014-bounty-to-add-dynarec-core-for-wii-u-port-of-beetle-mednafen-psx

@twinaphex twinaphex changed the title Dynamic recompiler Dynamic recompiler [$150] [BOUNTY] Aug 8, 2017

@twinaphex twinaphex changed the title Dynamic recompiler [$150] [BOUNTY] Dynamic recompiler [$200] [BOUNTY] Aug 8, 2017

@rtissera

This comment has been minimized.

Copy link

commented Aug 9, 2017

Is using PPSSPP code still considered the best approach as discussed here ?
#182

Or starting something from scratch ?
Written a custom dynamic is quite a beast, even if you don't rely on libjit / LLVM, I think using a self-contained IR + JIT existing engine as an efficient approach.
sljit looks like some small enough, self-contained, C based, BSD-licensed, good target for this task.

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Aug 9, 2017

The PPSSPP proposal was just an idea. In retrospect it might not be the best idea, and we might prefer something from scratch. I think the issue with just repurposing PPSSPP's code is the C++11 codebase and the fact that it might just be overkill for such a basic CPU as the PSX's R3000A compared to PSP.

The only real requirements I have are described above; it needs to be either C or C++98, it should be possible to easily add new backends later on (for instance, the aforementioned Wii U PowerPC backend, which is a separate bounty that anybody can fetch after this one is done) and it has to be a significant performance improvement over the interpreter. The high system requirements of Mednafen/Beetle PSX so far is still what limits the reach of this emulator and userbase compared to something like ePSXe and PCSX-R, and it also prevents the Vulkan renderer from really shining on Android since the current interpreter core is too slow even on a Shield ATV.

I am fine with somebody using a generic JIT engine provided it is fast, portable and it doesn't make us run into packaging issues. For instance, TinyTiger made an LLVM RSP dynarec some time ago for Parallel N64, but it has been exceedingly difficult to package libllvm into the core, not to mention that LLVM breaks their own APIs every once in a while, so I look back on that as kind of a code experiment failure that I'd wish to avoid in the future.

If sljit is a way better offering over LLVM and libjit for this task (both approaches which I think have kinda not really worked based on past experiences), then I'm OK with a bounty hunter giving it a shot.

@hrydgard

This comment has been minimized.

Copy link

commented Aug 10, 2017

Oh just go right ahead and grab PPSSPP's, as long as you're at least GPL 2.0+. It's not overkill, in fact it's fairly lean for what it is. It's C++11 but could very easily be backported to C++98 if desired, not much needs to be changed. Just delete the FPU and VFPU parts, delete a few more instruction implementations that will no longer be necessary, and adapt its interfaces to your code base.

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Aug 10, 2017

Well, I still think a custom approach might be best suited for this particular project. C++11 is certainly out of the question and the conditions state it should be either C or C++98. C++98 is already a compromise on my end since we would rather prefer C instead.

Also, very important - the dynarec needs to be PIC-compliant. I dont know if PPSSPP finally supports that but it didnt last time we did a libretro port of it, and that is a huge issue since libretro cores practically demand that. ToadKing had to make various patches for that which have long since gone out of date and which didnt cover absolutely everything.

@twinaphex twinaphex changed the title Dynamic recompiler [$200] [BOUNTY] Dynamic recompiler [$255] [BOUNTY] Aug 10, 2017

@hrydgard

This comment has been minimized.

Copy link

commented Aug 10, 2017

@twinaphex It's now optionally PIC-compliant enough for most purposes on x86-64. Sticking to C is an ideological choice, I'm not gonna debate that except noting that it would also be technically very easy to port to C if desired, though a lot of mechanical text-editing work for little benefit, given that it's super easy to link C++ with C.

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Aug 10, 2017

Well, if the PPSSPP dynarec can be made to be fully PIC compliant for all architectures, and if a C++98 port is not too much work, it could be considered an option and a bounty hunter could go for it. But full PIC compliance for all architectures here is an absolute requirement, it shouldnt be left at only x64.

@hrydgard

This comment has been minimized.

Copy link

commented Aug 10, 2017

Depends on the definition - if by PIC-compliant you mean that it doesn't need tricks to put various blocks of memory close to each other, which is the usual problem in emulators, then yeah, it was already complaint on the other architectures even before the recent changes to x86-64.

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Aug 10, 2017

This is the problem at hand -

http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/

Libretro cores typically are shared libraries that get loaded into a frontend by way of a dynamic linker. The code needs to be completely position independent for this purpose. Dynarecs are often a huge problem from this perspective if this hasnt been specifically catered to. I am thinking of the Ari64 dynarecs in Mupen64plus and Yabause, and also PCSX2's dynarec. Dolphin up until a few months ago also was not PIC-compliant.

PPSSPP back when we ported it also did not work reliably in libretro even after some of ToadKings PIC patches and there were still many writerest errors that could be spammed at random times with a messagebox. This was years ago however. If its fixed for x86 x64 with a specific optional define, that is a good first step. However, we need to guarantee that it will work reliably on other architectures as well.

@hrydgard

This comment has been minimized.

Copy link

commented Aug 10, 2017

Ah, right. Yes PPSSPP's dynarecs should no longer have any trouble with any of that.

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Aug 10, 2017

That's good to hear.

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Aug 10, 2017

If so, sure, if one feels so inclined, they can give it a shot. I will leave this decision up to whomever wants to take a stab at the bounty as to which approach they want to go for.

@twinaphex twinaphex changed the title Dynamic recompiler [$255] [BOUNTY] Dynamic recompiler [$305] [BOUNTY] Aug 11, 2017

@zherczeg

This comment has been minimized.

Copy link

commented Aug 28, 2017

(if you have questions about sljit, let me know)

@Denu8thell

This comment has been minimized.

Copy link

commented Aug 29, 2017

Alright, I've been looking into this for the past few weeks and I'm at a point where I feel like I understand this enough to be able to do this.

I'm going to try to adapt PPSSPP's, because it's just so close to being what we need.

@ajshell1

This comment has been minimized.

Copy link

commented Aug 30, 2017

Good luck you glorious bastard. Even if you fail, you'll be remembered.

@meepingsnesroms

This comment has been minimized.

Copy link
Member

commented Sep 2, 2017

@Denu8thell I looked at your fork and it seems to be going very well (already compiling for windows x86_32), is there any chance that armv7 android will be working in the next week?

By working I mean run-able not perfect.

@Denu8thell

This comment has been minimized.

Copy link

commented Sep 2, 2017

@meepingsnesroms Only the changes that needed to be made to memory stuff compile for Win32 right now, not the JIT engine itself. It's REALLY time consuming and tedious work, because I have to change all the logging, the way memory works, the way timing works, and past that a lot of the various bits specific to PSX aren't implemented (For instance, the CP0 & GTE commands, which are just interpreted at this point).

Past that, I'm trying to get it to work for x86 first, because that's the machine I have access to right now.

Plus, school is starting for me Tuesday, so I'm gonna have less time to look at this.

I think a week is VERY ambitious, but I'm trying to go as fast as I can.

@wiired24

This comment has been minimized.

Copy link

commented Sep 3, 2017

Best of luck @Denu8thell We're all rooting for ya

@Denu8thell

This comment has been minimized.

Copy link

commented Sep 17, 2017

Hey everyone,
It's been a while since my last update, so I just wanted to post what's going on:

Right now, I think I'm pretty close to getting it to work for x86 machines. I'm having some trouble with the way the memory model is working (The compiler is trying to compile instructions that are out of bounds, I'm pretty sure.). I hope to get it at least running before the end of this week, but we'll see.

@rz5

This comment has been minimized.

Copy link
Contributor

commented Sep 20, 2017

@Denu8thell, your latest commit mentions that your work can be compiled on win64. Is that your preferred OS for development?

If so, and if you are dependent on e.g. the MSVC project files, do say so, maybe some libretro guys can update those files to ease your task.

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Sep 20, 2017

Thanks for the feedback @Denu8thell. Looking quite forward to seeing this running. You can visit us at #retroarch and either me (Twinaphex) or r5 would be happy to have a dialogue with you and perhaps lend a helping hand where necessary.

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Sep 25, 2017

@Denu8thell I have been testing the branch on your fork.

So far, these are my findings:

1 - I get around 800 to 900fps on this device (x86_64 Windows). I compiled it with mingw and set HAVE_HW=1 and HAVE_JIT=1.
2 - However, I get no BIOS splash screen, and it doesn't seem to resume ingame. When I enable logging i do see it logging the timestamps though.

Have you been able to get this to work with any game so far? If so, I'd like to reproduce it. I'm also trying to see if I can get other people like @simias to maybe chime in and help you along with the timing if possible.

@rz5

This comment has been minimized.

Copy link
Contributor

commented Oct 14, 2017

@Denu8thell - Just in case you haven't seen it yet: https://pcsxr.codeplex.com/SourceControl/latest#pcsxr/libpcsxcore/ix86_64/iR3000A-64.c

pcsxr also has a dynarec, I believe that's one of the files related to it, might be good reference material.

@meepingsnesroms

This comment has been minimized.

Copy link
Member

commented Oct 14, 2017

It is good as a reference but should not be copied, the pcsx-rearmed dynarec has issues with 3d games and that is the main reason getting a beetle psx dynarec is important.

I know this is not the same dynarec since it is for x86-64 but it may have that issue as well.

@diego-rbb-93

This comment has been minimized.

Copy link

commented Nov 22, 2017

Any news on this?

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Oct 7, 2018

Hi there @nayslayer !

Yeah, I could certainly think of another core. Mednafen/Beetle Saturn is a Sega Saturn emulator that, much like Mednafen/Beetle PSX here, lacks a dynarec. It has even more steep system requirements than even Mednafen/Beetle PSX however, so it would be very beneficial if a dynarec could drastically lower system requirements.

The Sega Saturn uses two Hitachi SH-2 CPUs running at about 28MHz each. Let me know if this is something that interests you. Otherwise I can think of another core.

The repo can be found here -

https://github.com/libretro/beetle-saturn-libretro

@nayslayer

This comment has been minimized.

Copy link

commented Oct 8, 2018

Yeah, that looks good, thanks! I'm in the process of acquiring specs/sdks/games, once I do, I'll post an issue on the repo you provided.

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Oct 8, 2018

Awesome to hear! Dynarec in Beetle Saturn would be a definite game changer I'm sure.

@pcercuei

This comment has been minimized.

Copy link

commented Oct 13, 2018

Link to my own dynarec: https://github.com/pcercuei/lightrec

It's kinda slow as it calls back to C for each read/write, but with @senquack's trick and some proper high-level optimization (constant propagation, SSA) it shouldn't be too bad.

The nice thing with my dynarec is that it uses GNU Lightning as the code generator. Think about something like LLVM but much lower level. As such, it will work on x86, ARM, MIPS and PPC, all of them in 32 and 64-bit variants.

The other interesting thing is that I added a debug feature that allows you to run two instances in parallel and get detailed information as soon as a recompiled block does not behave correctly.

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Oct 13, 2018

Put another $100 into this bounty.

@twinaphex twinaphex changed the title Dynamic recompiler [$720] [BOUNTY] Dynamic recompiler [$835] [BOUNTY] Oct 13, 2018

@pcercuei

This comment has been minimized.

Copy link

commented Nov 19, 2018

Are there somebody already working on this?
I'm willing to throw two months of full-time work on this, but I don't want to step on someone else's toes.

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Nov 23, 2018

Hi there @pcercuei,

that's very gracious of you, thanks. I guess this all depends on where @simias stands right now. He has a dynarec branch on his repo. The last activity has been in September though.

If you guys can both bring this currently existing work by @simias to completion through a joint effort, would you guys be fine if we split the bounty 50/50?

All we ultimately care about is that we get this dynarec working sooner rather than later, and at this point after having waited over a year or so or longer, I think it might be best if we work with what currently already exists instead of having to build everything up from scratch and losing even more months.

So, what do both of you think about my proposal to work together on simias' dynarec and then split the bounty 50/50? It won't work of course if both of you don't agree on this, but I hope we can find some common ground.

@Klauserus

This comment has been minimized.

Copy link

commented Nov 23, 2018

hi. I spend 40 dollars to the bounty and i hope i can see a good beetle Emu on my Raspberry or Handheld console in Future (not a makeshift). Dear programmer, drink a Beer for me after work! I love your work. Greetings

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Nov 23, 2018

Thanks very much for the stimulus! We are now at $895!

@twinaphex twinaphex changed the title Dynamic recompiler [$835] [BOUNTY] Dynamic recompiler [$895] [BOUNTY] Nov 23, 2018

@pcercuei

This comment has been minimized.

Copy link

commented Nov 24, 2018

I think @simias is working on a "classic" mips32 to x86_64 dynarec. I want to work on a radically different design, loosely based on the one I already have, and honestly I think it would take me as much time to understand @simias' dynarec and learn x86 assembly than writing a first version of my improved dynarec.

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Nov 24, 2018

Hi there,

OK, so both of you working on the same codebase is not going to happen then.

I don't want to upset either of you since I know @simias has worked long and hard on his dynarec too (although it is not yet working), so how about this instead -

@pcercuei works on his own dynarec independently, upon completion he can get half of whatever this bounty is at right now. Plus you will get another $200 from the house (libretro) upon completion of this dynarec just as an additional thank you. So you'd be looking at $450 + $200. And maybe the bounty will still go up in the intervening time.

The other half of the bounty will still be kept whenever @simias reaches completion on his own dynarec. I am fine with alternate dynarec systems especially if they can later be repurposed to target other systems/devices as well. So I'd still very much appreciate simias' dynarec being completed.

Does this sound agreeable?

On our end, we just want something to start working as soon as possible. The dynarec bounty started August 2017, I would be very glad if by end of December we finally have some games starting to run with either of both dynarecs that is at least 2 to 4x as fast as the current interpreter core.

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Nov 28, 2018

@pcercuei @simias Can I get a response from either of you on what I wrote above?

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented Dec 4, 2018

OK, after talking to @rz5, we have come to the conclusion that the only thing that matters here is the results and which of the solutions is delivered first.

We ideally would like to be able to wrap up this bounty within two months or so, we originally started this bounty last year on August, and while we have been fairly patient, we do want to be able to wrap this up by March 2019 or so.

Whomever delivers this solution first and when it has been found to be working gets the bounty. He/she can use his/her own implementation however he likes. We'll even likely throw in a nice little bonus as a show of appreciation for getting this daunting task finished.

The conditions of the bounty can be found in the original post. Also, you can always correspond with us through e-mail by sending an email to libretro@gmail.com if you want to be able to talk in private.

So, @pcercuei, I'd say you are welcome to give it a shot as far as we are concerned.

@coccofresco

This comment has been minimized.

Copy link

commented Mar 8, 2019

So... Everithing dead again?

@roflcopter777

This comment has been minimized.

Copy link

commented Mar 8, 2019

I wouldn't be surprised

@billywade

This comment has been minimized.

Copy link

commented Mar 8, 2019

Your best bet is to follow the individual dynarec repos to keep an eye on this.

@roflcopter777

This comment has been minimized.

Copy link

commented Mar 8, 2019

That's a bit much isn't it? Hard to pinpoint the exact URL for those repos, so...

@billywade

This comment has been minimized.

Copy link

commented Mar 8, 2019

Here's for @simias, I can't find @pcercuei 's repository. https://github.com/simias/beetle-psx-libretro

@roflcopter777

This comment has been minimized.

Copy link

commented Mar 9, 2019

So nothing new is known then.

@RyanBram

This comment has been minimized.

Copy link

commented Mar 29, 2019

I am not sure if it is a good idea, but...

... is it possible to ask @hrydgard the PPSSPP author to work around this?

He is proven to be the most expert person on this matter.

@hrydgard

This comment has been minimized.

Copy link

commented Mar 29, 2019

@RyanBram Wish I had time to jump on stuff like this, but I don't, sorry.

@Klauserus

This comment has been minimized.

Copy link

commented Apr 4, 2019

Hi

I have spend a little bit money. I am sad about dont hear about news. I see a n64 dynarec and a ppsspp dynarec. Very cool, but why is psx so unfame? I wish my psx games mobile on switch... i like to help, but i am not a programmer. The only thing i can do is spending money.

Please dear Person X/Y make my happy and make a dynarec für madnafen psx.

@simias

This comment has been minimized.

Copy link
Collaborator

commented May 28, 2019

I haven't had much time in the past months to work on this unfortunately and it looks like I won't have much time in the near future either. If somebody wants to take over from my branch I'm open to help/mentor them to the best of my capacities. I guess the only prerequisite is being decent at C and not being afraid to spend a lot of time debugging obscure bugs in games, the rest I should be able to explain. It could be an opportunity to learn about emulator programming and maybe get ~$900 out of it too!

@twinaphex

This comment has been minimized.

Copy link
Member Author

commented May 29, 2019

Alright @simias, that is a friendly offer there. Hope that this will lessen the steep requirements somewhat.

To everybody else in this thread -

simias' repo is here (branch for dynarec) -

https://github.com/simias/beetle-psx-libretro/tree/dynarec

If anybody wants to build on top of this work and claim the bounty, you've been given permission by @simias himself to do so, and he is even willing to help explain things that are not clear.

@coccofresco

This comment has been minimized.

Copy link

commented May 29, 2019

It should be in @m4xw 's to-do-list, if I'm not wrong

@m4xw

This comment has been minimized.

Copy link

commented May 29, 2019

Not beetle.

@coccofresco

This comment has been minimized.

Copy link

commented May 29, 2019

Such a shame. Lets hope it will be portable to beetle, than!

@roflcopter777

This comment has been minimized.

Copy link

commented May 29, 2019

Darn, oh well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.