Introducing RPCS3 for arm64

As of today, we are officially announcing arm64 architecture support for RPCS3! This major feature has been heavily worked on over the last few months, and allows RPCS3 to natively run on Linux, macOS and Windows arm64 devices!

Index

1. Background
2. Supporting arm64 on our CPU LLVM Recompilers
3. The 16K memory page-size problem
4. Pull requests
5. Challenging the limits of PlayStation 3 emulation
6. Platform showcases
7. Available emulator downloads
8. A note about other mobile platforms
9. Special thanks to the developers

Background

Initial support for arm64 devices started in 2021 after the Apple M1 series launched. We started exploring running rpcs3 on arm64. Thanks to the efforts of RPCS3 core developer Nekotekina, we got a basic running build compiled for arm64 in December of 2021 that wasn’t able to run anything. After some cleanup from kd-11 to get RSX working on arm64 and more enhancements from Nekotekina, we finally got samples running and rendering by Jan 2022. Only PPU/SPU interpreters worked correctly, resulting in very poor performance, but it was the first step to getting RPCS3 running correctly on future arm64 devices. Initial efforts were limited to linux support as it is widely available and accessible to developers without hardware lock-in. A few months later, a contributor Jeff Guo submitted a series of patches bringing the x64 macOS branch up to speed. Some major strides for macOS were made at this stage, such as understanding how the new JIT mechanism works. An attempt was made to get LLVM working but by late 2023 we still only had working builds on arm64 without LLVM support.

Supporting arm64 on our CPU LLVM Recompilers

RPCS3 graphics developer kd-11 had been working behind the scenes on improving arm64 support on Asahi Linux since 2021. Initially, there was no access to graphics drivers so performance did not matter but things kept improving on that front over the years to the point where Asahi could actually be a daily driver. The arm64 LLVM integration work was revisited in late 2023. The initial target was linux as any issues could be tracked down to source level for debugging. kd-11 quickly uncovered the reason LLVM did not work with RPCS3 JIT was due to how the emulator handles guest code. Since RPCS3 was initially written with x86 architectures in mind, some architectural decisions hinged on x86-specific behavior. One of them was that every few blocks, the guest would exit back to the host to handle state checks as well as unwind the stack. RPCS3 uses tail-call-optimized frames for all the JIT blocks but x86 consumes stack during any calls that need to be reclaimed through a ret chain or reloading the stack pointer. This is different than arm64 which uses a dedicated register for “linking” calls. A ret-chain does not exist with stackless frames on arm64. When the JIT code executes the first return, the CPU will enter an infinite loop jumping to it’s current position and hang because the link register is not updated with the previous position.

Naturally, there are plenty of ways around this problem as with all things in computer science. We explored some of these approaches in early 2024 mainly to achieve a proof of concept. The first one was easy – if we provide a minimal stack for every function call and mimic x86 behavior. We keep the frames themselves stackless but track the previous call address and reload it to unwind. Unfortunately, this doesn’t work reliably since the basic blocks assume all stack space is scratch and will clobber the return address every once in a while leading to random crashes. Several other variations of this were attempted including reclaiming some registers for a shadow call stack pointer. They all work, but have different upsides and downsides. For example, some of them required modifying LLVM to accommodate RPCS3’s JIT architecture. Which wasn’t ideal as it required us maintaining a fork of LLVM. Another quick solution is to just replace all returns with a far jump to some host gateway that fixes up the register state and we can exit. This also proved challenging since our JIT blocks can loop between blocks and do recursion. The performance hit became too high for such a strategy to work.

By late February 2024, kd-11 had some samples running with a customized LLVM fork. And made further improvements over March resulting in homebrew running under arm64. After a brief hiatus, kd-11 made a breakthrough, and some commercial titles were able to run on arm64 with PPU LLVM by late June 2024! The proof-of-concept stage was now over. It was time to pick a winning strategy and ship the product.

In the end, kd-11 settled on a IR transformer that analyzes the JIT IR generated for x86-64 and makes tweaks to accommodate arm64’s requirements. The idea is simple – generate IR once for a reference architecture (in this case amd64) and then transform it to target other architectures as required. LLVM makes this kind of work possible since everything is represented as an IR before compilation. LLVM basic blocks have some constraints with regards to flow control and since our JIT blocks are always callable from a gateway, there is an ABI of sorts in place with regards to which registers will hold what value – e.g the guest thread context always lives in the first register passed to the block. This setup was extended to provide extra information at compile time that the transformer can piggy back on to correctly identify the location of objects. We don’t need to store the entire call chain for example, we just need to know the location of the closest host gateway. This approach worked really well and by late July, most commercial games were booting and running fairly well but there were more problems that required addressing.

The 16K memory page-size problem

By default, x86-based operating systems provide page granularity of 4KiB. The PS3 natively also supports 4KiB granularity and does expect that the operating system will correctly align memory allocations as such. However, most arm64 platforms today come with a minimum page granularity of 16KiB. This usually means better memory performance as modern era devices use more memory with larger objects.

Support for 16K pages was added to the emulator in 2021 and was fairly well tested before using interpreters. Most games don’t notice that the page sizes are 4x larger than what they requested and this made the porting efforts much easier than we expected on that front. However, when we finally got LLVM running, it became clear that the performance impact can be quite massive. Emulators like RPCS3 use dirty page tracking to handle cache evictions for textures. While modern games have large textures that take up a lot of space, the PS3 is a different beast. Not only are many textures tiny, all user-facing GPU objects are often represented as textures. This includes texel buffers, uniform buffers, shader storage buffers, etc. The sizes can vary wildly here and evicting a single 16K page can cost us a lot in re-uploading resources every draw call. Fortunately, not many games seem to be affected by this, but there are some unfortunate outliers with very poor performance on 16K platforms.

Pull requests

Early work

#11315 – Initial Linux aarch64 port (PPU only)
This is the original work from Nekotekina that brought basic ARM support to RPCS3, on early 2022. Only PPU was initially supported and LLVM was not supported at all. This work is mentioned here for historical purposes as it is the pillar of the current ARM port. This wasn’t the only pull request of course and there were many follow-ups polishing compatibility on ARM devices.

  • Update asmjit dependency (aarch64 branch)
  • Disable USE_DISCORD_RPC by default
  • Dump some JIT objects in the rpcs3 cache directory
  • Add SIGILL handler for all platforms
  • Fix resetting zeroing denormals in thread pool
  • Refactor most v128:: utils into global gv_** functions
  • Refactor PPU interpreter (incomplete), remove “precise”
    • Instruction specialisations with multiple accuracy flags
    • Adjust calling convention for speed
    • Removed precise/fast setting, replaced with static
    • Started refactoring interpreters for building at runtime JIT (due to poor compiler optimisations)
    • Expose some accuracy settings (SAT, NJ, VNAN, FPCC)
    • Add exec_bytes PPU thread variable (akin to cycle count)
  • PPU LLVM: fix VCTUXS+VCTSXS instruction NaN results
  • SPU interpreter: remove “precise” for now (extremely non-portable)
    • As with PPU, settings changed to static/dynamic for interpreters.
    • Precise options will be implemented later
  • Fix termination after fatal error dialog

LLVM bring-up pull requests

#15182 – Minor arm64 improvements
This was the first arm64 pull request of 2024, merged on February 11st, and allowed Arkedo games to run fine on arm64 with PPU Interpreter and SPU Recompiler LLVM. Almost all other games still did not work properly. SPU LLVM would hang very early after booting up the games and audio did not work as a result.

#15869 – gl: Fixes for wayland (asahi linux, aarch64)
Fast forward several months of internal work, kd-11 starts wrapping up months of internal work and prepares to open a series of pull requests to upstream arm64 support, with a second pull request opened on August 1st. This is a smaller one allowed OpenGL to start working on Asahi Linux with the arm64 Linux builds of RPCS3.

#15904 – aarch64/cpu: Add LLVM support
This PR introduced the initial draft of the LLVM transforms that allowed JIT to work on arm64. The work was developed and tested entirely on Asahi Linux for testing.

#15915 – rsx: Fix fragment constants decoding for non-x86 platforms
Some RSX functionality was broken when running on non-x86 CPUs and needed touching up. Since this was high performance code, it had been rewritten in SSE and AVX for x86 and the cross-platform fallback was untested.

#15925 – aarch64/llvm: Handle processing of leaf nodes
This PR improved the LLVM transformer to handle “leaf nodes”. A leaf node is a compute-only basic block that does not make any external tail calls. These types of blocks will attempt to return to the caller after executing and were not correctly handled in the original work. They are surprisingly rare as most normal blocks will end up calling a syscall or library function at some point while normally breaks the traversal chain by starting a gateway exit.

#15962 – aarch64/llvm: Improve compatibility
This PR reworked the transformer a fair bit. Initially, some optimizations were done by eliminating tail calls and replacing them with static branches. This worked very well and performance was good, but LLVM could sometimes clobber it’s own registers even when clobber information was provided. We restored tail calls to some capacity here and a micro-assembler was introduced to write proper inline assembly blocks for injecting into the IR with proper dependency resolution.

#15971 – aarch64 fixes
One challenge we faced with x64 support was decoding the reason for a segfault. A table was written that basically had instruction patterns for matching whenever a segfault is received so that we can determine in a cross-platform manner why the fault was reported. This information was very incomplete for arm64 and many instructions were being miscategorized.

#15974 – Rework aarch64 signal handling
Replaced the instruction decoding tables from the previous PR with a proper parsing of the machine context passed in to Unix signal handlers. This is a lot more reliable as we can check the CPU register state at the time of the fault and know for sure why a fault occurred.

#15981 – aarch64: CPU branding info and misc improvements
This PR introduced some work to help identify arm64 processors. Unlike x86 where you can use CPUID, no textual representation of the CPU name and details exists at all and we have to infer the details from some register values.

#15987 – aarch64: Support for apple exceptions
This PR started the porting of the arm64 work to macOS. One advantage of starting with Linux is that the changes are compatible with other unix-like OSes including macOS. On the first build, things just worked, but exceptions needed to be reworked since the machine context is stored in a different format than Linux.

#15992 – macOS: Implement remaining portions for native arm64
Some minor alterations were needed to get the JIT running correctly on macOS. This PR implemented reserving the x18 register on macOS as it is always reserved for Rosetta2 use and is not preserved during syscalls. That solved random crashes where the x18 register would magically change to 0 in the middle of execution and crash. Some extra code was also added to help read the CPU name, number of cores, etc.

#16011 – aarch64/gl: Misc fixes
Maintenance PR fixing some compiler warning and fixing a bug in our OpenGL backend that caused shadows to break in some titles.

#16022 – aarch64: Support calloc patch blocks
With most of the base functionality done, it was time to start supporting extra features such as game patches. This PR fixed a crash that occurred when a “calloc” style patch instruction was used. These instructions force-inject leaves into the code and add extra jumps instead of returns. This was causing the transformer to generate invalid sequences that led to crashes.

#16035 – aarch64: Fix compilation for windows-on-arm (msys2)
This was the initial windows on arm support PR. RPCS3 was successfully compiled for windows arm64 using msys2 and clang. The visual studio portions of RPCS3 are not compatible with Microsoft’s ARM64 API as it is missing too many intrinsics that we need otherwise.

#16058 – arm64: Fix remaining issues for Windows on ARM
This PR finally got us working windows-on-arm builds that could successfully run demos. Not much testing was done due to lack of test hardware. While windows-on-arm has been around for over a decade (previously windows RT) their devices are largely ignored by the masses and it is difficult to find any testers who run compatible hardware. We expect this to become less of an issue as the new Snapdragon X laptops and tablets become more common.

#16070 – arm64: macOS CI
These changes from nas introduce the automatically compiled macOS builds for arm64, with auto-updater support.

#16148 – arm64: Linux CI
These changes from kd-11 introduce the automatically compiled Linux builds for arm64.

Challenging the limits of PlayStation 3 emulation

And by now you might be thinking, if there’s a Linux arm64 build for RPCS3, which requires an armv8.2-a CPU, at least 8GB of RAM, and an OpenGL 4.3 or Vulkan capable GPU/drivers, what’s stopping it from running on an Raspberry Pi 5 device? How far can we challenge the limits of emulating the console known for being the most resource demanding to emulate still 18 years after its release?

To put this to the test and support arm64 development, AniLeo acquired a Raspberry Pi 5 device. This low-cost arm64 device costs around £68/€93/$85, plus £4/€6/$5 for an Active Cooler.

The device was setup with Arch Linux ARM to make use of all the latest packages, in order to be able to compile RPCS3 on device. The device was also overclocked to squeeze out more performance, the CPU was overclocked to 2900MHz (+400MHz) and the GPU was overclocked to 1060MHz (+100MHz).

#15978 – vk: Support v3dv, allow creating device without textureCompressionBC
We started by trying to running games on the default Vulkan render, but this failed as the mesa v3dv driver for Broadcom GPUs is missing full textureCompressionBC support, due to hardware limitations. However, not all was lost, since the BC1-BC3 formats are supported, and that’s all that RPCS3 needs.
We then added a workaround on RPCS3 to allow the Vulkan render to boot even without this feature reported as supported by the v3dv driver. We could now boot games through Vulkan.

Unfortunately the Vulkan render would only work for a small amount of time, before hanging the entire system and requiring the device to be power cycled. This meant that we had to shift to testing with the OpenGL render. Fortunately, the results were great, with the mesa’s v3d OpenGL for Broadcom GPUs being able to render all tested games correctly with no visual bugs.

However, initial results from testing dozens of games were not very promising, games were displaying very low performance overall and no game seemed to run well, even simple ones. After some investigation, we realised the Broadcom VideoCore VII GPU in the Raspberry Pi 5 is not only unbelievably weak, but was also several times weaker than the PlayStation 3’s own GPU – the RSX. This means that Raspberry Pi 5 is not capable of rendering these games at 720p.

#15977 – config: Set minimum allowed resolution scale to 25%
After testing with different rendering resolutions, we saw a great performance boost as the rendering resolution was lower, as the bottleneck shifted away from the GPU back to the CPU.
Unfortunately, even 360p rendering of these 3D games proved too much for this GPU. We then decided to settle on rendering games at the PlayStation Portable screen’s resolution, 272p, by setting the resolution scale at 38%.

Here we can see God of War 1 tested at both 720p (PS3) and 273p (PSP) resolutions. Running the game at its PS3 resolution of 720p, we can see it struggles to render at around 10 FPS. With PSP resolution, however, it runs at a smooth 30 FPS. With this new piece of data, we were now seeing several games running at Playable performance, which are showcased in the next section.

Platform showcases

macOS arm64 on Apple M1 (macOS Sequoia)

RPCS3 x64 build running under Apple’s Rosetta2 x64 -> arm64 translation layer on the left;
RPCS3 arm64 build running natively on Apple Silicon on the right, showing a huge performance improvement!

Linux arm64 on Apple M1 (Asahi Linux)

Unsurprisingly, RPCS3 runs very well on the M1 when using Asahi Linux. While the Vulkan driver for Asahi is still not ready, we can make use of OpenGL which can render games with decent performance. Unfortunately OpenGL is still not as performant as Vulkan so games still run faster under macOS when using the MoltenVK layer.

Linux arm64 on Raspberry Pi 5 (Arch Linux)

As what might come as a surprise for many, several PS3 games are be Playable on Raspberry Pi 5, albeit for the lower resolution. A lot of Playable games will not perform well on Raspberry Pi 5 due to its hardware performance limitations, we can still push it to its limit to run several games at 30 FPS, rendered at PSP resolution.

Windows arm64 on Windows 10 for ARM

This was the last platform to be supported, for one main reason: kd-11 only had access to macOS and Linux on arm64, and no one else in our team owns any kind of arm64 device that can run Windows. In order to be able to develop this platform, an arm64 virtual machine was temporarily acquired, as physical devices that can run Windows on ARM are expensive.

At first, support was attempted through the msvc compiler, but due to many encountered issues, it was deemed that this was only going to be possible by using msys2 and compiling RPCS3 with clang.

A lot of debugging and two pull requests later, we had RPCS3 running on arm64. Due to the lack of testing hardware, only samples were tested. Homebrew games should work without issue, but commercial titles are likely to run into problems due to Windows-on-ARM having a hard requirement for ASLR which doesn’t play too nicely with some aspects of RPCS3’s JIT engine.

Available emulator downloads

Without further ado: you can now download Linux arm64 and macOS arm64 binaries from the Download page on our website. These two versions now join our existing Windows x64, Linux x64, macOS x64 and FreeBSD x64 builds.

Windows arm64 binaries are not distributed at this point. This is due to the low availability of hardware to develop and test with, as well as missing automatic compilation and deployment through GitHub CI. Users on Windows must compile their own binaries locally until we start distributing them.

FreeBSD arm64 binaries are not available. FreeBSD support and the FreeBSD Ports x64 builds are maintained by FreeBSD contributors. We have not worked on or tested any support for this platform, as we do not use it ourselves, but we invite any contributors to add FreeBSD arm64 support if they wish to do so. The work done on the other platforms should make this endeavour a much easier task now.

A note about other mobile platforms

Adding arm64 architectural support is a key step to ensure long term preservation of the PlayStation 3 console, as arm64 CPUs make their way into the conventional desktop and laptop market.

We are aware it comes with its own disadvantages, such as having to deal with toxic users that have harassed other emulator developers in the past, like the brilliant developers behind AetherSX2, or redistribution of modified builds of an emulator, often violating their FOSS license, while claiming credit for work they didn’t do themselves. As it has already happened with other emulator projects being re-distributed in these malicious ways.

We are also aware of the increase of scam applications that portray themselves as a PlayStation 3 emulator while being malware, or that redistribute RPCS3 under a different name and claim it is a new emulator. Some of them are even vetted in Google’s Play Store. Unfortunately Google haven’t acted on the reports we have made, and these scam apps continue to be exposed to users.

We are thus reminding once again that there are no other PS3 emulators that can run PS3 games. Any footage you see is either completely fake, or recorded on a real console, or through RPCS3 itself and distributed under the claim it’s another emulator with a different name.

For these reasons, we are disallowing Android and iOS discussion in our communities. We have no intention of porting RPCS3 to these platforms at this time, so no discussion on these topics is needed. Unfortunately, this blanket decision is ultimately needed due to the high toxicity of several individuals in the Android community, who refuse to take no for an answer, some of which have already been banned from our communities.

Special thanks to the developers

We would like to thank the specific contributions to this big feature development. As a reminder, RPCS3 as a whole is made possible thanks to the contributions of many current and past developers and contributors at Team RPCS3 since 2011.

kd-11
– Lead developer for Linux, macOS and Windows arm64 support
– Lead graphics developer for OpenGL and Vulkan support on arm64
– Linux arm64 automated build deployment CI

Nekotekina
– Initial Linux arm64 support, laying the groundwork for the full development of this feature

nastys
– macOS arm64 automated build deployment CI
– macOS arm64 build testing

AniLeo
– Raspberry Pi 5 development support for Linux arm64
– Raspberry Pi 5 / Linux arm64 extensive game testing
– Website back-end development for the arm64 builds

DAGINATSUKO
– Website front-end development for the arm64 builds
– Design of the promotional arm64, Raspberry Pi 5 and Apple Silicon banners

Megamouse
– Bug fixes related to the macOS arm64 build

schm1dtmac
– Bug fixes related to the macOS arm64 build

elad335
– CPU emulation performance optimisations for lower end hardware

This blog post was written by kd-11 and AniLeo.

RPCS3 Inside Look: A Deep-Dive into Hardware and Performance Scaling!

Hey everyone! Today we’re going to talk about something that’s a little different than what you are used to in the progress reports. We’ll be going in-depth on how certain hardware and software configurations could significantly affect your performance in RPCS3.

There are several aspects that could make RPCS3 not perform as well as it should, and memory speeds is one of them. In our case, memory performance will be stressed by RPCS3 in several ways:

  1. Cell emulation: SPUs access to main memory goes through DMA. This is a beastly exercise to emulate all on its own.
  2. RSX emulation.

RSX memory operations fall into two major categories: Upload and Download. Upload operations include transfer of textures, shaders, and shader data (vertex buffers and other register configuration tables) from the host CPU to the host GPU. This process is usually optimized by the GPU driver to occur asynchronously and with heavy use of batching. It is bandwidth heavy, as the sets of data are rather large and transport has to go through PCI-E. We do a lot to hide this issue, and for the most part it works well, but if your memory is too slow or if you are stuck on an older PCI-E revision, the transfer lag can have a huge performance impact, especially if a GPU sync is required.

Download operations for instance include transfer of textures and arbitrary data from the host GPU to the host CPU. This one has very serious implications on performance because we can’t really hide the memory latency for the transfer operation. Most of the time the memory in question will be accessed by Cell without warning, which means we have to stop everything until the GPU has processed the information we need, and then we read all that data back over PCI-E all while our CPU thread is blocked. It is for this very reason that we have the ‘buffer options’ disabled by default: to reduce the penalty of this hard stop as most games might trample on older GPU-resident data without really needing to read it back later, in which case we can just pretend nothing existed for that memory block. This means that it’s also not advisable to run RPCS3 with your GPU usage maxed out or close to it as your GPU will not be quick enough to respond to these random synchronization requests. There is a lot of optimization that could be done in this area however, with a very good predictor that can guess with high accuracy whether or not a memory block will be accessed by the CPU soon and start queueing up the GPU instructions before it happens.

Continue reading RPCS3 Inside Look: A Deep-Dive into Hardware and Performance Scaling!

Progress Report: September 2019

Welcome to September’s Progress Report! Firstly, we’re aware that this report is severely late and would like to apologise for the delay. RPCS3’s progress reports are solely written by volunteers and most of our regular writers could not contribute to this report due to personal commitments. Going forward, we are actively looking at ways to streamline the report to allow us to publish them in a timely manner. If you hate seeing RPCS3’s reports get delayed and would like to contribute to them, please apply here.

In addition to the following report, further details of Nekotekina and kd-11’s work during September and upcoming contributions can be found in their weekly reports on Patreon. This month’s Patreon reports are:

Status update from kd-11 (2019-09-14)
Status update from Nekotekina (2019-09-25)
Status update from kd-11 (2019-09-30)

Table of Contents

Major Improvements
Games
Other Improvements
Conclusion

After the large improvements in August, September featured a lull in testing games as our regular testers were focused on testing various pull requests opened during the month. Due to this, most categories only showed modest changes. However, the Loadable category did decrease from 16 games down to just 14 games now.

Game Compatibility: Monthly Improvements Table
Game Compatibility: Monthly Status Pie-chart

On Git statistics, there have been 17640 lines of code added and 7957 removed through 89 pull requests by 14 authors.
Continue reading Progress Report: September 2019

Progress Report: August 2019

Welcome to August’s Progress Report! Firstly we would like to apologize for the delay in publishing this report. RPCS3’s progress reports are solely written by volunteers and a few of our regular writers could not contribute to this report due to personal commitments. If you hate seeing RPCS3’s reports get delayed and would like to contribute to them, please apply here.

If you thought July was a big month for RPCS3, then prepare yourself for this progress report. This month saw 20 pull requests from eladash alone as he set a goal to have all his work merged in RPCS3 before his conscription service began. Not wanting to be outdone, Nekotekina and kd-11 also made a dozen pull requests each improving various parts of the emulator. We’ve got a lot to go over so let’s get straight into it!

In addition to the following report, further details of Nekotekina and kd-11’s work during August and upcoming contributions can be found in their weekly reports on Patreon. This month’s Patreon reports are:

Status update from kd-11 (2019-08-16)
WIP Screenshots from kd-11 (2019-08-16)
Status update from kd-11 (2019-08-31)

Table of Contents

Important Announcements
Major Improvements
Games
Other Improvements
Conclusion

August saw a major change in the way games are counted in the compatibility statistics with all online multiplayer games in the Intro category and below being excluded. This was done to better represent the state of the emulator’s progress as these titles did not work as the servers that they wish to connect to no longer exist. Thus, even if RPCS3 becomes 100% complete, these games will not work unless somebody sets up a private server and emulates the original server accurately. These titles are still present in the compatibility list and are represented with a lightning bolt symbol next to their title. While they will still show up in all search queries, they will no longer be included in our statistics to showcase a more accurate picture of RPCS3’s development.

Moving on to actual improvements, our testers finally picked up the slack from the past few months and extensively tested the Ingame category which gave the Playable category its largest increase of the year. Every other category saw large decreases with Ingame shedding 88 games and Intro and Loadable recorded one of their largest drops ever percentage wise with drops of 17% and 20% respectively. An effort was also made to merge duplicated titles in the compatibility list which also aided the drop in these categories. As mentioned in the previous month’s progress report, the Nothing category doubled in size to 4 games due to erroneous tests, but this has since been fixed bringing the category back down to 2 games.

On Git statistics, there have been 8536 lines of code added and 5418 removed through 71 pull requests by 15 authors.
Continue reading Progress Report: August 2019

Progress Report: July 2019

Welcome to July’s Progress Report! Firstly we would like to apologise for the delay in publishing this report. RPCS3’s progress reports are solely written by volunteers and a few of our regular writers could not contribute to this report due to personal commitments. If you hate seeing RPCS3’s reports get delayed and would like to contribute to them, please apply here.

July was an absolute whirlwind of development that saw 60 pull requests merged from both our regular developers as well new contributors. That’s almost 2 pull requests merged everyday! This month, Nekotekina focused on improving TSX performance while kd-11 implemented a second round of bug-fixes that improved multiple AAA titles. On the other hand, eladash ironed out new features to help games go beyond their existing framerate caps and GalCiv implemented microphone support to finally allow RPCS3 to better emulate SingStar and other similar titles. Ohh and let’s not forget the surprise progress made with Metal Gear Solid 4 as well! There’s a lot to cover, so let’s jump straight into it.

In addition to the following report, further details of Nekotekina and kd-11’s work during July and upcoming contributions can be found in their weekly reports on Patreon. This month’s Patreon reports are:

Status update from kd-11 (2019-07-10)
Status update from kd-11 (2019-07-23)
Status update from Nekotekina (2019-07-31)

Table of Contents

Major Improvements
Games
Other Improvements
Conclusion

For the compatibility list, it was another quiet month as testers were predominantly occupied with testing pull requests before they were merged. The Playable category remained the largest, while the Ingame category showed a small increase. A similar decrease can be seen in the Intro and Loadable categories, dropping the Loadable category to an all-time low of just 20 titles. Finally, the Nothing category doubled in size to 4 games, although it should be noted this was possibly due to an inaccurate report from a tester, which is to be corrected soon.

On Git statistics, there have been 7396 lines of code added and 3334 removed through 60 pull requests by 15 authors.
Continue reading Progress Report: July 2019

New Demon’s Souls 60FPS+ patch

Hello, I’m Whatcookie, an RPCS3 contributor. I’m here today to talk about the brand new 60FPS patch for Demon’s Souls. But before we discuss the details of the patch, let’s first take a look at some 4K 60FPS gameplay:

Demon’s Souls has long been one of the most popular titles for RPCS3. When it went ingame for the first time it made gaming headlines everywhere. I had been following RPCS3 pretty loosely at the time, but when Demon’s Souls went ingame I finally tried out the emulator. Back then the graphics were quite broken, and I was lucky if the framerate went over 20FPS. But despite all that it was still amazing to me. I thought to myself “Wow, it will be so incredible when the game is playable at 30FPS… maybe in 2 years or so”. The game ended up being very playable much earlier than I expected, all the way back in 2017. Since performance was so solid I thought that it would only be a matter of time before someone out there would make a 60FPS patch.
Continue reading New Demon’s Souls 60FPS+ patch

Progress Report: June 2019

Welcome to June’s Progress Report! This month saw a wide variety of… bzzzt we interrupt this broadcast for an important announcement!

RPCS3’s progress reports are written solely by volunteers and we’re looking for more dedicated writers to help us write them. If you have the knowledge, time and are willing to help, please apply here. And secondly, we have recently added functionality that makes it possible to unlock the framerate limit of many games. While this exciting new feature doesn’t work on every game, some big titles such as Uncharted 1-3, The Last of Us, Red Dead Redemption and more are able to go over their framerate cap of 30FPS for the first time! We require the help of the community to submit test results for as many games as possible to determine the effectiveness of the feature. For more details, please click here.

Now back to our regular coverage! This month saw a wide variety of important contributions from both lead developers, Nekotekina and kd-11 as well as many of our usual contributors. June also marked an important milestone in compatibility for the emulator as shown below. In this report, we’ll be going over the implementation of native MSAA in RPCS3 and mutli-threaded RSX workload support, as well as improvements to PPU scheduling and a significant overhaul to the DevOps environment.

In addition to the following report, further details of Nekotekina and kd-11’s work during June and upcoming contributions can be found in their weekly reports on Patreon. This month’s Patreon reports are:

Status update from kd-11 (2019-06-10)
Status update from Nekotekina (2019-06-24)
Status update from kd-11 (2019-06-25)

Table of Contents

Major Improvements
Games
Other Improvements
Upcoming
Conclusion

Although June was a slow month for compatibility improvements due to our testers taking a break, it did quietly mark the monumental milestone of the Playable category finally becoming the largest category in our compatibility list! This came to fruition from years of development, testing and re-working to ensure a perfect balance of accuracy and performance to emulate the PlayStation 3. While there is still much to be done, the momentum from these milestones continue to accelerate development. In addition to this, the Intro and Loadable categories decreased due to a few games being moved to Ingame or Playable for the first time. The Ingame category also saw a net decrease due to further maintenance done by merging duplicate game entries. This culminated into our second milestone, where the combined percentage of the Loadable and Nothing categories dropped below 1% for the very first time!

Game Compatibility: Game Status
Game Compatibility: Monthly Improvements (June 2019)

On Git statistics, there have been 24284 lines of code added and 14514 removed through 42 pull requests by 12 authors.
Continue reading Progress Report: June 2019

Progress Report: May 2019

Welcome to May’s Progress Report! Firstly we would like to apologise for the delay in publishing this report. RPCS3’s progress reports are solely written by volunteers and a few of our regular writers could not contribute to this report due to personal commitments. If you hate seeing RPCS3’s reports get delayed and would like to contribute to them, please apply here.

This month saw some major leaps by Nekotekina and kd-11 on the SPU and RSX fronts. Nekotekina implemented SPU PIC support while kd-11 improved the surface cache implementation. Meanwhile, Megamouse made multiple improvements to the UI, GalCiv overhauled the DualShock 3 pad handler and ruipin tackled regressions in the SPU LLVM backend when using Mega SPU block size.

In addition to the following report, further details of Nekotekina and kd-11’s work during May and upcoming contributions can be found in their weekly reports on Patreon. This month’s Patreon reports are:

Status update from kd-11 (2019-05-09)
Status update from Nekotekina (2019-05-14)
Status update from kd-11 (2019-05-27)

Table of Contents

Major Improvements
Games
Other Improvements
Conclusion

This month RPCS3 reached one of the most significant milestones in game compatibility. After intensive testing and merging of duplicates, as mentioned in the previous month’s report, the Playable category has tied with the Ingame category at 43.71%. RPCS3 has surely come a long way to have the Playable category stand on the cusp of overtaking the Ingame category. On the other hand, Intro section saw a modest drop while the number of Loadable and Nothing games remained unchanged. For a more detailed look, you can view the compatibility history page to see exactly which games had their status changed this month.

Game Compatibility: Game Status
Game Compatibility: Monthly Improvements (May 2019)

On Git statistics, there have been 9391 lines of code added and 5430 removed through 45 pull requests by 12 authors.
Continue reading Progress Report: May 2019

Progress Report: April 2019

Welcome to April’s Progress Report! Firstly we would like to apologise for the delay in publishing this report. RPCS3’s progress reports are solely written by volunteers and a few of our regular writers could not contribute to this report due to personal commitments. If you hate seeing RPCS3’s reports get delayed and would like to contribute to them, please apply here.

This has been a very busy month, which saw many contributions from our regular developers and even a few newcomers. Major improvements have been made to RSX emulation by kd-11, fixing the texture cache and improving on the shader decompiler. Meanwhile, eladash in his usual style, fixed a multitude of bugs relating to savedata handling and the PPU/SPU interpreters/recompilers. Numan (Inviuz) implemented a fringe syscall needed for Metal Gear Solid 4 to boot and Nekotekina squeezed quite a bit more performance out of the SPU LLVM path. To also improve the visual aspect of the emulator drysalter created two beautiful new themes and lastly GalCiv expanded DualShock 3 Support to Linux. These and many more improvements have all contributed to making RPCS3 both a better piece of software and a better emulator, moving a bunch of new games into the Playable category.

In addition to the following report, further details of Nekotekina and kd-11’s work during April and upcoming contributions can be found in their weekly reports on Patreon. This month’s Patreon reports are:

Status update from kd-11 (2019-04-07)
Status update from kd-11 (2019-04-23)

Table of Contents

Major Improvements
Games
Other Improvements
Conclusion

This month RPCS3 reached another milestone in game compatibility. It’s the first time that the Playable category surpasses 40%! As a result, the Ingame and Intro categories see an equivalent, while the Loadable category goes down to 29 games. We are also gearing up to undertake further maintenance to the compatibility list by identifying and merging duplicate entries in the coming months! For a more detailed look, you can view the compatibility history page to see exactly which games had their status changed this month.

Game Compatibility: Game Status
Game Compatibility: Monthly Improvements (April 2019)

On Git statistics, there have been 9921 lines of code added and 2967 removed through 113 commits by 16 authors.
Continue reading Progress Report: April 2019

Progress Report: March 2019

Welcome to March’s Progress Report! If you were left wanting more after last month’s report, then your wait is over. March saw massive strides in all facets of the emulator as multiple work-in-progress pull requests from our regular developers were finally completed and merged. To start things off, Nekotekina implemented a new LLVM-based SPU interpreter, updated the LLVM submodule to version 9 and fixed the “Out of memory” errors faced by some games. On the other hand, kd-11 continued his mission to improve the RSX texture handling which fixed issues faced in over two dozen titles while GalCiv implemented native support for the DualShock 3. Finally, elad335 made a host of improvements to various core components improving performance and accuracy in an assortment of titles, most notably God of War 3, when running on Windows.

In addition to the following report, further details of Nekotekina and kd-11’s work during March and upcoming contributions can be found in their weekly reports on Patreon. This month’s Patreon reports are:

Status update from kd-11 (2019-03-02)
Status update from Nekotekina (2019-03-05)
Status update from kd-11 (2019-03-18)
Status update from Nekotekina (2019-03-30)

Table of Contents

Major Improvements
Games
Other Improvements
Conclusion

This month saw more maintenance work done to the compatibility list where duplicate game IDs for the same game were merged into one single entry. A grand total of 118 threads were merged allowing for a fairer representation of RPCS3’s compatibility at this time. Adding to this, our community of testers continued their efforts in acquiring and testing obscure titles that had not been tested recently. The results of this revealed that many of the titles in the Ingame and Intro categories were now indeed Playable and moved according. Thanks to the dual effect of both efforts, the Playable category saw a marginal increase while the Ingame and Intro categories saw a sharp decrease in total number of games listed. Finally, thanks to elad335’s improvements to sys_vm, Doom 3: BFG Edition moved from Nothing category straight into the Playable category, leaving just two more titles in the Nothing category! For a more detailed look, you can view the compatibility history page to see exactly which games had their status changed this month.

Game Compatibility: Game Status
Game Compatibility: Monthly Improvements (March 2019)

On Git statistics, there have been 6331 lines of code added and 2573 removed through 105 commits by 9 authors.
Continue reading Progress Report: March 2019