>>303439
100% running a Windows emulator on Linux would be an easier time than the current state of 7th Gen emulators. 7th Gen in general is in that awkward spot where it's got significantly more complex architecture than other generations, was the point DRM was being deliberately included on the machine, and unlike 8th Gen, has a wide array of varying games people want to play rather than just optimising an emulator to play Bloodborne and have almost the entire catalog sorted (on top of having more PC-friendly architecture that makes ports easier, hence why half it's catalog is already whored out) (not even mentioning the XB1 essentially being a glorified PC with full crossplay).
>PlayStation consoles were always notorious for system complexity (e.g. PlayStation, PlayStation 2). Sony's technology being developer-unfriendly makes it emulator-unfriendly as well, and RPCS3's steep system requirements prove it. Even if done properly, an LLE approach would be performance suicide, as some things just have to be abstracted enough to get high framerates in games. The situation is so bad that Sony seems to be incredibly hesitant to produce an official PS3 emulator for the newer PlayStations, even though the PS5 is sufficiently powerful, possibly because they wouldn't be able to justify the extremely high potential development cost to investors.
>There are two major bottlenecks at play:
<<Cell Broadband Engine - consists of two architectures that developers have to program for; PowerPC, and... whatever the SPEs really are; and you have a great formula for high system requirements, SPU hardware environment is the furthest thing from a x86 PC processor. "Cell Broadband Engine" (i.e. the PS3 CPU) leaned into SIMD with the SPUs recklessly, ease of programming be damned, but it broke records in 2006. Four pipelines of 512-bit wide ALUs per core is an absolute bonkers amount of computational capability. The main issue is that SPU code is stored as data blobs anywhere the game shoved it into: main executable constants, resource files, generated on the fly...anything goes, and it’s impossible to extract before it is submitted to SPEs for processing (same with the RSX shaders). Another half is that a way SPU are utilised in later games is a sort of microservices with context switching and load balancing (i.e several microtasks code can be uploaded/replaced/switched into single SPE memory at runtime during one frame cycle of game logic). Like SPURS for example. Old style SPE programming from early games with fixed systems bound to specific cores and not changed since works well with static recompilation. Unfortunately, this way was suboptimal for games and developers quickly went into "microtasks" design. SPEs are closer to VUs from the PS2 than a GPU. They're a SIMD cluster, don't be fooled by their apparent similarity to GPUs. GPU are low throughput but very wide. SPEs are also wide, but not nearly as much so. However, their individual thread throughput is insane even compared to a something like an RTX 4090. It's not possible to beat SPUs 1:1 (it's ALL vector, it doesn't have scalar registers at least not general-purpose ones), they have 128 registers and very low latency SRAM, almost no memory fetches and everything is async. Although AVX-512 comes close in performance (at 5+ GHz). GPUs on the other hand are around 10-100x slower, but that's just because of how their cores are designed and the fact that SPU kernels are optimized to run in much smaller groups. There's too much working against emulation at 3.2 GHz rate since most SPU instructions need many instructions on PC (like dozens in some cases), so the PC side needs to be an order of magnitude faster.
<<RSX (Reality Synthesizer): The PlayStation 3 GPU went unemulated for a long time, simply because of how many components were undocumented; the RSX Reality Synthesizer is a custom-designed chip similar to the GeForce 7800 GTX developed by Nvidia specifically for the PlayStation 3. It's not well-documented, and developers have to figure out how it displays graphics and graphical effects. Without access to Nvidia's resources, which would normally be included with an SDK, this is very difficult. Something of note is that this GPU was also managed by two different memory units with very disparate frequency speeds; 1) 256 MB of GDDR3 RAM clocked at 650 MHz with an effective transmission rate of 1.4 GHz, and 2) up to 224 MB of the 3.2 GHz XDR main memory via the CPU (480 MB max).
>In practice, smaller devs use the PPE most of the time, but AAA use everything what PS3 had. It took an eternity for AVX-512 to arrive, with Intel releasing their first implementation only in 2016; but wide availability in consumer grade PCs only started with AMD's Ryzen 7000 series in late 2022. Fortunately, most of the optimizations in RPCS3 still apply for AVX2, e.g., the 512bit checksum is still much faster than a full comparison, and the LTO, rotated checksum, and the other optimizations added also apply for machines without AVX-512. The RPCS3 developers use ahead-of-time recompilation via an LLVM. RPCS3 is not just compiling the code it runs, it also needs to compile a real-time environment simulator e.g. the 128x128bit register file, LS SRAM, the very weird memory flow controller, etc
tl;dr it's chugging along because it's basically the final boss of emulation development (aside from Switch 2), but it's taken years to get to this usable point and it's still going to take a while from where it's currently at