Welcome back to the first progress report of the year. Quite a large number of fixes and improvements have been made already, and as you can see below from the big compatibility bump we are starting the year off strong. kd-11 has made some major improvements that increase stability and functionality including increasing performance with Ryzen and implementing a Native UI to RPCS3. While Nekotekina has continued to review people’s changes, making sure everything was in a good enough state to be merged, he continued to work on the core of RPCS3. Megamouse has also made many improvements to the way RPCS3 handles input allowing a bunch of games to progress further and he also fixed other issues with the UI.
On the compatibility database statistics, over a hundred games moved out of the Nothing, Loadable, and Intro sections and in to Ingame or Playable. In addition, the Nothing section has now fallen below 2% of tested games, and hopefully Loadable will follow next. This means RPCS3 is on the right track to ensure accuracy and compatibility with the largest number of titles possible.
On GitHub statistics, 7,454 lines of code were added and 2,160 were removed by a total of 14 authors.
RPCS3 is an open source Sony Playstation 3 emulator for Windows and Linux. Currently, it has two full-time paid developers, and numerous volunteer developers. RPCS3 has existed since 2011, but development took off a year ago when the Patreon launched and Nekotekina followed by kd-11 began working on the emulator full time. This post will summarize what interesting developments and progress has happened in the last year. If you want to see how the codebase has changed over time, you can head over to the full list of merged PRs for 2017 and check it out. As seen on the GitHub statistics page we had 630 pull requests merged during 2017, and many of these contain numerous commits. That is a lot of code!
RPCS3? What Does That Even Mean?
When you think about it there is a tradition of Sony emulator names in this style. You have ePSXe, PCSX2, JPCSP, PPSSPP, and now RPCS3 as examples of PS1, PS2, PSP, and PS3 emulators. There is a story behind all of these names of course, but in the case of this little PS3 emulator it was given this name by the founder DH (who no longer works on the project). It is an abbreviation and combination of Personal Computer (PC) and PlayStation 3 (PS3). PC + PS3 = PCS3. What does the R stand for? DH and BlackDemon recollect that it used to stand for Real as back in 2011 there were only fake malware emulators around. Then at some point DH who is from Ukraine started saying the R stood for Russian which is what we roll with today as Nekotekina who joined in late 2013 and quickly became one of the biggest developers and the architect, is from Russia. So RPCS3 stands for Russian Personal Computer Station 3.
In this image of the old branding from 2016 RPCS3 is written with the Russian letter я, though this letter is in fact not pronounced like a Latin R at all (it is [ja] as in “yard”).
A short introduction
Where Were We One Year Ago?
One year ago in January of 2017 RPCS3 development had stagnated. The emulator itself ran almost no games properly, only roughly 20 titles were playable, and most of these were simple 2D games. Quite a few more did show intros or even go ingame, but due to generally very poor performance, bugs, and crashes almost nothing was really playable.
January 15th, 2017, tkoham opened an issue suggesting that RPCS3 launch a Patreon. A long discussion starting on GitHub and moving on over to a new and at the time “private” Discord channel and a few days later, the Patreon was launched. Shortly after, the Discord server went public and the new website launched. At the time, only a handful of commercial games even booted, and only the simplest of games, such as the Arkedo series, were anything near playable. The UI was unwieldy, installing games was tedious, and manually picking LLE modules was an immense challenge. Development had slowed considerably, with only Nekotekina and a handful of others making occasional commits.
What a way to end the year, eh? We started the last month of 2017 with a bang with RPCS3 taking major steps towards emulating many heavy hitting AAA titles, including quite a few exclusives like Uncharted and God of War. Some moved in to Loadable, others Ingame, and a few are even playable now. More can be read about this here. While these changes were made last month and received a post of their own, they had an impact on many other games that were discovered this month, and such incredible work deserves recognition. This progress report will focus on progress over the month of December. First and foremost, below is a video summary and report of various games that improved this month. Take a look, and read on for even more detail!
First of all, let us have a look at the compatibility database statistics. As we predicted last month the number of games in the Nothing category is now less than 100! A year ago this with the Loadable and Intro categories represented the biggest chunk of registered games, most simply did not work more or less.
However we are now making quite a drastic change to how compatibility is counted. Above different versions of the same game are counted separately. So for example instead of simply having one entry for Demon’s Souls, there are currently four entries: the european disc and PSN versions, and the american disc and PSN versions. This could even become six entries if someone were to test the japanese counterparts.
This is a very traditional way for emulators to look at compatibility, but because of the nature of such a “modern” console like PS3, there can be a lot of different versions of the same game. We have different regions: Europe, America, Japan, Asia, Korea, Hong Kong. And for each region the disc version and the PSN version.
So as can be seen below, we are merging all entries of the same game under the same media type (disc or digital), into a single entry.
There are some differences on compatibility between media types, like Demon’s Souls, where only the disc versions are currently playable, while the PSN versions fail to get past a black screen. But every disc version is playable the same, and every PSN version fails the same, so it makes sense to simply count the disc versions Playable once, and the PSN versions as Nothing once in the statistics.
Also note that not every game is merged yet, so the entries count is likely to go down again in the next month.
November was one of the most interesting months of the year thanks to the huge amount of games that jumped out of Nothing into the Ingame/Playable categories. This is in part thanks to the hard work announced in December 1st, which made many previously non-working big titles now start working on RPCS3. Of course, some of the progress towards this announcement was merged gradually during the month of November. In this Progress Report, major emulation improvements will be detailed, followed by a list of noteworthy, interesting, and representative games that improved from these, and lastly individual contributions will be looked at closer.
First things first, the compatibility statistics. In November we saw the category of games that do absolutely Nothing go down by over 100 games, and this while not taking in account any of the games that had reported improvements in December!
We are therefore making a prediction right now: thanks to the SPU/RSX fixes, amongst several other improvements: the number of known games that do Nothing will be less than 100 before the end of the year!
That is quite the feat because when the RPCS3 project got revitalized in January, thanks to Patreon and the full time employment of Nekotekina we had less than 100 games that were Playable – that to quite a lower standard than today. And the category Nothing didn’t even exist because we argued that “What is the point? Almost every game does Nothing anyway”. How far have we come!
Looking at the GitHub statistics for November 16 authors have pushed 172 commits with roughly 11,000 added lines of code, and 5,000 deletions.
Yes, you’ve read correctly. Many of the much awaited exclusives are now finally starting to be emulated by RPCS3. In this blog post, you’ll learn which games we know to have improved and how we’ve done it.
But first, check out this awesome teaser:
There were two main changes to the SPU emulation that brought us to this point of allowing so many newer titles to progress past ‘Intro.’ Let’s take a quick look at both individually.
SPU Interrupt Fix
Many titles in RPCS3 ‘hang’, but in the case of the titles mentioned above, they do not actually crash, and the fps counter would still change with just a black screen. This normally would be mistaken for RPCS3 just being slow and the game taking a bit to load, but opening up the debugger in RPCS3 tells a different story. The games would loop over the same code on both the PPU side and SPU side. In this case, they are waiting on something, but what?
‘The Last of Us’. More like – ‘The Last Loop That Will Ever Execute’
Moving the PC to address 0 of an SPU thread explains more. Most games will have just 0 (null) written there, but some actually have a branch there.
October was a huge month for RPCS3. Our lead graphics developer, kd-11, implemented High Resolution Rendering and made many improvements to the emulator. While Nekotekina made some general improvements to the emulator, which will be discussed in this report, he also bought some parts and assembled a new computer with a future-proof CPU which will allow him to debug RPCS3 more efficiently, faster, and allow him to make sure newer instruction sets like AVX-512 work properly with RPCS3 when the right time comes. You can find more details on the latter and also discuss further on it at https://www.patreon.com/posts/pursuing-avx-512-15151688
Starting off with the compatibility statistics as usual, the Intro/Loadable/Nothing categories keep growing small and Ingame/Playable titles keep increasing. We’ve also hit 500 playable games this month!
Looking at the GitHub statistics, 16 authors have pushed 131 commits to the master branch. Here 180 files have changed and there have been 12,626 additions and 5,068 deletions of lines of code. Below some of the major improvements from these code changes are summarized.
One of the most anticipated features has just been added to RPCS3! High resolution rendering allows users to play at resolutions far exceeding what the PS3 could handle. If you thought your favourite PS3 games were starting to look a bit dated, just wait until you get to experience them in up to 10k! Although, we doubt many users will have the setup necessary to benefit from 10k today, emulation is all about preserving for tomorrow.
The video above showcases various popular titles with a side-by-side comparison from 720p (native PS3 resolution) to 4k rendering with 16x anisotropic filtering in RPCS3. The difference is quite incredible in titles that have high quality assets. There is a lot of detail that just wasn’t visible at 720p. This feature is available for every PlayStation 3 game running on RPCS3. The only exception being that it does not yet work with Strict Rendering Mode. Games that require this setting will have to wait a bit longer before they can benefit from high resolution rendering.
Rendering a modern PC game in high resolutions such as 4k, while beautiful, is quite taxing on your hardware and there is often a massive hit in performance. However, since most of the workload for RPCS3 is on the CPU and GPU usage is low, there is a lot of untapped performance just waiting to be used. All processing is done CPU side, and as far as the GPU is concerned it is simply rendering 2006 era graphics (yes, the PS3 is 11 years old now). We’re happy to report that anyone with a dedicated graphics card that has Vulkan support can expect identical performance at 4k.
Anisotropic Filtering (AF)
High resolution support wasn’t the only thing that was added in this update! Another reason for such a massive upgrade in visual fidelity is having full 16x AF support. This greatly improves how textures can look, especially when viewed at an angle. Take a look at the below screenshots of Ni no Kuni as an example of the default AF vs forced 16x. The difference is especially noticeable on the ground inside the gate.
Ni No Kuni with default AF (left) and forced 16x AF (right)
September was quite the exciting month. Our lead graphics developer, kd-11, made major improvements to graphics emulation while Nekotekina, among many things, implemented initial networking support. This progress report will provide an overview of major changes and games that improved.
First of all, here are the compatibility statistics for this month. As usual the category of games that do nothing is shrinking while more and more games become playable.
Looking at the GitHub statistics, 15 authors have pushed 131 commits to the master branch. Here 216 files have changed and there have been 9,185 additions and 7,028 deletions of lines of code. Below some of the major improvements from these code changes are summarized.
August was a month of bug fixes and rewriting old code. In this report some general emulation improvements will be explained, followed by a closer look at some popular and representative games. Lastly, individual contributions will be covered and plans for the future will be detailed.
First and foremost are the compatibility numbers for August. Finally there are more games that are playable than completely not working! In fact, less than a quarter of all tested games do not at least show something on the screen. Just a year ago there wasn’t even a compatibility database or listing of games that did nothing as almost every games was expected to do nothing or at best be loadable! A lot of the improved games are actually the result of LLE GCM from July as testing and updating the forums and the compatibility database took quite some time. That said, a lot of games improved from new changes this month, which will be covered below.
Looking at the GitHub statistics, 20 authors have pushed 179 commits to the master branch. Here 190 files have changed and there have been 8,587 additions and 3,876 deletions of lines of code. Below some of the major improvements from these code changes are summarized.
Greetings. I am kd-11, graphics developer for rpcs3 with a mid-month update on latest developments on the emulator.
As many are already aware, a lot has been going on lately with the new changes to the RSX (the PS3 GPU) emulation, dubbed vertex rewrite. This change moves a lot of vertex processing duties from the CPU to the GPU where they rightly belong and as a result there are massive performance gains especially with OpenGL but also with Vulkan in geometry heavy scenes.
Most if not all users are probably aware by now, but dedicated graphics cards exist on a physically separate board. This means data has to be moved to and from it through the PCI-E bus which is quite fast. However, while it is high bandwidth, it is also high-latency. That means you cannot just send something over there and expect to get it immediately available for the next draw call. Instead, the GPU has to wait for data to be prepared and then signaled that data is ready for processing before drawing begins. This is a general simplification, but it helps illustrate the point. The RSX on the PS3 doesn’t work the same way however. It has near direct access to the XDR main memory on a PS3 and ‘pulls’ data directly from main memory as though it were local memory. It is somewhat similar to integrated graphics memory in this case. That means data is not ‘pre-packaged’ for transport to the PS3 GPU since the memory is virtually unified from the point of view of the RSX. When using Vulkan, drawing is not scheduled until the whole command queue is flushed mitigating the impact of transfer since data will likely have been uploaded beforehand, but for OpenGL this was a big bottleneck.
The second issue was that the emulator was doing a lot of computation on the CPU on how to read vertex data from main memory, essentially pre-packaging the data into formats easy for GPUs to use. This is a very slow process and also very memory intensive (hence the ‘Working buffer not enough’ crashes). Enabling a debug overlay with the old method shows some games taking up to 200ms to prepare vertex data for one frame (Hellboy: The Science of Evil). This is obviously not optimal. The impact could be lowered by using more threads for vertex processing, but with the number of threads already needed to emulate the PS3’s multi-core processor, it was a problem. Spawning 8+ vertex processing threads reduced the time spent processing vertices, but cost other threads to starve and performance would drop significantly. The solution was to shift the work to the GPU instead and not touch it in any way. Just copy the data block and the GPU could fetch the data it needed for itself, mimicking the behaviour of the real hardware.