Short Waves 0.0.1: new PS3 emulator from InoriRus

Discovered by DH:
InoriRus used a static recompiler (which explains such high speed on all the samples), but real homebrew or commercial games can modify sections of his code so the emulator has to react to this by recompiling those modified blocks again (known as dynamic recompiler).

Is that so? the last time I talked with DH (well it was a long time ago) I was under impression he was using the same scheme: loading ELF and parse its code to generate native code, which sounds to me as static recompiling as well. So I guess he changed his mind when discovering SMC (self-modified-code) was not that rare even for ps3?

Honestly, you can also mix static recompiling and interpreting as a fallback or static recompiling and dynamic recompiling as a fallback. But I guess it may mean more works under the hood.

Discovered by DH:
InoriRus used a static recompiler (which explains such high speed on all the samples), but real homebrew or commercial games can modify sections of his code so the emulator has to react to this by recompiling those modified blocks again (known as dynamic recompiler).

Is that so? the last time I talked with DH (well it was a long time ago) I was under impression he was using the same scheme: loading ELF and parse its code to generate native code, which sounds to me as static recompiling as well. So I guess he changed his mind when discovering SMC (self-modified-code) was not that rare even for ps3?

Honestly, you can also mix static recompiling and interpreting as a fallback or static recompiling and dynamic recompiling as a fallback. But I guess it may mean more works under the hood.

well, his emulator is closed source and he is working on it by himself, i dont think its wise to work on a big (and difficult) project as a PS3 emulator alone.

It is true that GPU drivers are buggy, but a focus on DirectX also means Windows only. So no Mac or Linux. And theoretically speaking no Android/iOS version either (assuming OpenGL -> OpenGL ES is easier than DirectX -> OpenGL ES, completely disregarding performance, and interest in porting, and working on ARM).

ppsspp is a fine example of good multi platform developement. That thing seems to run on everything, and does so with amazing performance.

But to be fair, nothing else than a über gaming rig, which probably runs Windows anyway, will be able to run rpcs3 for like 10-20 years, so whatwever.

I agree with you but I say the more renderings I have to choose much better

e.g in Dolphin
Directx 9/10/11 -> (windows only)
OpenGL / OpenGL ES 3.0 -> Cross-platform Windows / Linux / mac os x and Android.

Some games working graphics fine with Opengl plugin but others working better with Directx renderer you can complete best compatibility hardware in general .

anyway ps3 emulation is far from complete

You are right. Just a remark: Those differences between OpenGL and DirectX are mostly caused by bad implemented (or missing) features. The problem of Short Waves is not being DirectX based since there are a lot of pro's and con's for each choice (after all, RPCS3 using OpenGL has a lot of compatibility problems with Intel GPUs). The problem is being *closed source*. And until this changes I won't show any interest in SW as a developer.
At this point of complexity in consoles, I only see future in open source projects: If someone wants to see DirectX in RPCS3, its fine and everyone will be very happy with this. Just fork, add the backend and send a pull request. Easy as pie.

I completely agree. There is absolutely no reason to keep the source closed. It is not good for anyone, including the developer himself who will be completely on his own. A very strange move indeed. Perhaps he wants to sell it or something

Also, while a choice between OpenGL and DirectX can be good for end users since it will help to work around different bugs, it also means more code to maintain, and perhaps some duplication of effort for the developers. Unless someone really want to maintain a plugin of course. In any case, I would rather see one really good OpenGL plugin that works across platforms, than several where none is quite perfect.

Discovered by DH:
InoriRus used a static recompiler (which explains such high speed on all the samples), but real homebrew or commercial games can modify sections of his code so the emulator has to react to this by recompiling those modified blocks again (known as dynamic recompiler).

Is that so? the last time I talked with DH (well it was a long time ago) I was under impression he was using the same scheme: loading ELF and parse its code to generate native code, which sounds to me as static recompiling as well. So I guess he changed his mind when discovering SMC (self-modified-code) was not that rare even for ps3?

Honestly, you can also mix static recompiling and interpreting as a fallback or static recompiling and dynamic recompiling as a fallback. But I guess it may mean more works under the hood.

well, his emulator is closed source and he is working on it by himself, i dont think its wise to work on a big (and difficult) project as a PS3 emulator alone.

Nah I didn't mean this way (why presuming the source of this guy is needed to have the same?). I just mean that both static and dynamic recompiling are not necessarily antinomic. Very long ago I already tried static recompiling and interpreter as fallback on pcsp with some psp games. I had globally only a x2-3 boost because the source I generated from static recompiling was not that highly optimized. But honestly, I cannot say whether it is worth while doing so as I didn't go further.

This emulator could have a future. I'm not against static recompilation, like hlide stated it's a good fallback method and considering this developer is working alone, it seems like a logical first step.
However, in my opinion, keeping this project as closed source would be a big mistake. There's no point on coding a PS3 emulator with a restrict team or even alone. The extension of the PS3 architecture would require a lot of time from developers and without some sort of funding (more than donations), people would start giving up, since it would not be sustainable for anyone.
While RPCS3 had a rough start, it became clear that a PS3 emulator must encompass a lot of wise choices, being the most important of all having a big community working on it.

Dynamic recompilation is necessary, and it's one of RPCS3's goals (I think it's on our roadmap). I believe DH already rewrote most of PPU with this in mind.
Also, I can't tell if the developer InoriRus has completely discarded the implementation of dynarec or if it's just stating that it won't be done in a near future.

As for OpenGL vs. DirectX, that's not really a big issue. When RPCS3 becomes stable enough, we can easily handle DirectX and OpenGL, either with a plugin structure or adding support for both internally.

Obviously, due to InoriRus choices, this WIP emulator is naturally optimized to show results. Unfortunately, that won't be enough later on.
I'm really interested in this approach to RSX. It would be nice to use the direct translation method as an intermediate solution for DirectX testing.

Successful dynamic recompilation requires one simple thing: optimization. PowerPC 64 and x86 are completely different architectures. There is no way to efficiently map registers and instructions on-the-fly to make produced code faster than interpreter. You need to write good optimizer. And this is the task comparable with developing a real compiler. With static approach you can use some real compiler: for example, gcc, as it's done in short waves.
And by the way, all those samples works such high speed without recompiling - it is just a single interpreter. A manual on how to use recompilation will be available later.

Successful dynamic recompilation requires one simple thing: optimization. PowerPC 64 and x86 are completely different architectures. There is no way to efficiently map registers and instructions on-the-fly to make produced code faster than interpreter. You need to write good optimizer. And this is the task comparable with developing a real compiler. With static approach you can use some real compiler: for example, gcc, as it's done in short waves.
And by the way, all those samples works such high speed without recompiling - it is just a single interpreter. A manual on how to use recompilation will be available later.

Hi, nice to have you in the forums.
Indeed, dynamic recompilation is a massive challenge.
A standard interpreter is a logical starting point and should be more than necessary to run homebrew, samples and even smaller commercial games. But anything more demanding than that will require huge optimization.
The direct translation of RSX plays a big part here, since it's cutting of a lot of processing resources from the emulation process.

Successful dynamic recompilation requires one simple thing: optimization. PowerPC 64 and x86 are completely different architectures. There is no way to efficiently map registers and instructions on-the-fly to make produced code faster than interpreter. You need to write good optimizer. And this is the task comparable with developing a real compiler. With static approach you can use some real compiler: for example, gcc, as it's done in short waves.
And by the way, all those samples works such high speed without recompiling - it is just a single interpreter. A manual on how to use recompilation will be available later.

Since you are here , you may tell us more about how you achieve that static recompilation: offline or online?
offline: you have an external tool to generate a native source from a binary game that you include in your emulator when building it (emulator binary per game) or do you build a separate dll to be optionally fetched when launching a game?
online: do you build a dll at the time you launch the game so the emulator dynamically loads it then executes the game through the dll.

Since you are here , you may tell us more about how you achieve that static recompilation: offline or online?
offline: you have an external tool to generate a native source from a binary game that you include in your emulator when building it (emulator binary per game) or do you build a separate dll to be optionally fetched when launching a game?
online: do you build a dll at the time you launch the game so the emulator dynamically loads it then executes the game through the dll.

Offline. Source can be generated with emulator, no external tool needed. But to build it you need an external compiler. Separate dll can be optionally loaded when launching a game.

To generate dll source add the following line to sw_emu.ini:
ppu_recompiler = 3

After that run emulator and source for dll will be generated to recomp folder.