9 ms·
Playstation 2 GS emulation – the final frontier of Vulkan compute emulation
- nightowl_games 2y agoHow far do I gotta read before this article will expand the "GS" acronym? Interesting stuff but I'm being left behind here.
- wk_end 2y agoIt stands for “Graphics Synthesizer” - Sony’s name for the “GPU” in the PS2.
- nightowl_games 2y agoThat helps immensely. Surprised the author assumed this was implicit.
- chaboud 2y agoAmong the intended audience, it likely is. I think this article is here to equally amuse and traumatize folks familiar with the system. The Emotion Engine (CPU) to GS (GPU) link was what made the PS2 so impressive for the time, but it also made it somewhat hard to code for and immensely hard to emulate. If I recall correctly, the N64 has something like 4x the memory bandwidth (shared) of the PS1, and the PS2 had roughly 6x (3GB/s) the system bandwidth of the N64. However, the PS2's GS RAM clocked in at 48GB/s, more than the external memory bandwidth of the Cell (~25GB/s), which meant that PS3 emulation of PS2 games was actually done with embedded PS2 hardware. It was a bonkers machine. I don't think workstation GPU bandwidth created 50GB/s for another 5-6 years. That said, it was an ultra simple pipeline with 4MB of RAM and insane DMA requirements, which actually got crazier with the Cell in the PS3. I was at Sony (in another division) in that era. It was a wild time for hardware tinkering and low level software.
- djtango 2y agoThanks for sharing! Back then the appeal of console games to me were that beyond a convenient factor, they were also very specialised hardware for one task - running games. I remember playing FF12 (IZJS) on a laptop in 2012 and it ran very stable granted that was 6 years post release but by then had the emulator issues been fully solved? Re. Wild time for low level programming I remember hearing that Crash Bandicoot had to duck down into MIPS to eke out every extra bit of performance in the PS1.
- fmbb 2y agoPretty sure all 3D PS1 games tapped into assembly for performance. The most “famous” thing about Crash programming is probably that it’s all in lisp, with inline assembly.
- wk_end 2y agoI don’t think either of these things are true. By the mid-90s, C compilers were good enough - and CPUs were amenable enough to C - that assembly was only really beneficial in the most extreme of cases. Sony designed the Playstation from the jump to be a 3D machine programmable in C - they were even initially reluctant to allow any bit-bashing whatsoever, preferring devs used SDKs to facilitate future backwards compatibility. No doubt some - even many - PS1 games dropped down into assembly to squeeze out more perf, but I doubt it’s anything like “all”. As for Lisp, Crash used a Lisp-like language, “GOOL”, for scripting, but the bulk of the game would’ve been native code. It was with Jak & Daxter that they really started writing the game primarily in a Lisp (GOAL, GOOL’s successor).
- boricj 2y agoDefinitely not. I'm reverse-engineering Tenchu: Stealth Assassins and the original Japanese release's game code is written entirely in C as far as I can tell. It does use the Psy-Q SDK which contains assembly, but it's not something that the game developers have written.
- dagmx 2y agoBoth PS1 and N64 games were beyond the generation where direct assembly was required to achieve necessary performance. Compilers were good enough by that point in time for the vast majority of games.
- dagmx 2y agoIt’s fairly well known in the specific domain space the author is dealing with, so I think it’s fair to treat it as implicit. But for more reading https://www.psdevwiki.com/ps2/Graphics_Synthesizer https://www.psdevwiki.com/ps2/Graphics_Synthesizer The author has a bunch of other things in their post they don’t expand upon either which are significantly more esoteric as well though, so I think this is very much geared for a particular audience. A few link outs would have helped for sure.
- Abishek_Muthian 2y agoI realized from recent Anand Tech sunset article[1] that 'GPU' was coined by Nvidia way later than I expected - >A lot of things have changed in the last quarter-century – in 1997 NVIDIA had yet to even coin the term “GPU” [1] https://www.anandtech.com/show/21542/end-of-the-road-an-anandtech-farewell https://www.anandtech.com/show/21542/end-of-the-road-an-anan...
- BlackLotus89 2y agoHow about the "Sony GPU" (1994) used in the PlayStation? Edit: source https://www.computer.org/publications/tech-news/chasing-pixels/is-it-time-to-rename-the-gpu https://www.computer.org/publications/tech-news/chasing-pixe...
- dagmx 2y agoI believe the distinction from NVIDIA was that they considered their product as the first all in one graphics unit > a single-chip processor with integrated transform, lighting, triangle setup/clipping, and rendering engines that is capable of processing a minimum of 10 million polygons per second It’s kind of arbitrary, even when you take out the processing rate. But prior to that there was still a significant amount of work expected to be done on the CPU before feeding the GPU. That said, the term GPU did definitely exist before NVIDIA, though not meaning the same thing we use it for today.
- pjmlp 2y agoTI chips for arcades are considered one of the first. "The TMS34010, developed by Texas Instruments and released in 1986, was the first programmable graphics processor integrated circuit. While specialized graphics hardware existed earlier, such as blitters, the TMS34010 chip is a microprocessor which includes graphics-oriented instructions, making it a combination of a CPU and what would later be called a GPU." https://en.m.wikipedia.org/wiki/TMS34010 https://en.m.wikipedia.org/wiki/TMS34010 And they weren't alone in the history of graphics hardware.
- 2y ago
- ammar-DLL 2y ago[dead]
- tetris11 2y agoFor anyone wondering: > A dynamic recompiler is a type of software that translates code from one instruction set architecture (ISA) to another at runtime, rather than ahead of time. This process allows programs written for one platform to be executed on another platform without needing to modify the original code. Dynamic recompilation is often used in emulators, virtual machines, and just-in-time (JIT) compilation systems. Is this what Dolphin does most of the time, or is all handcrafted at the assembly level?
- ammar-DLL 2y ago(Citra, Panda3DS, Vita3K, touchHLE, and unidbg and more ) use dynamic for ARM CPU Emulation but Dolphin/cemu use same concept to emulate PowerPC Chips too PS4 emulators use different approach tho
- troad 2y agoMy (limited) understanding is that most serious emulation is done via dynarec these days, particularly past the fourth / fifth gen of consoles. For newer consoles, traditional interpreted emulation isn't going to be fast enough to be playable, so dynarec is the only realistic option.[0] For the older systems, it's more of a nice-to-have performance boost, particularly as a lot of people now like to play those with demanding upscalers and shaders. (Some older games, like Sonic 2, were designed around composite video artefacts and don't look right without CRT shaders.) [0] Things get fuzzier on near-current gen consoles, which are more like PCs, and may hypothetically be best emulated with some kind of translation layer not unlike Proton.
- bonzini 2y agoHow does this approach compare to Dolphin's ubershader?
- Sesse__ 2y agoBasically, not at all. Dolphin's ubershader does one thing; simulate fixed-function blending/texturing using modern flexible hardware. (It was already an old technique when Dolphin adopted it, by the way.) This project is a complete renderer, with the rasterizer and all, and as you can see from the text, it includes an ubershader for the blending. The shader doesn't draw triangles, it just gets called for each point in the triangle and with some inputs and gets to decide what color it is. It's vaguely like comparing a full CPU emulator with something that implements the ADD and MUL instructions.
- armada651 2y ago> Dolphin's ubershader does one thing; simulate fixed-function blending/texturing using modern flexible hardware. Just to clarify, Dolphin's specialized shaders simulate fixed-function blending/texturing too. What's different about ubershaders is that a single shader can handle a wide variety of fixed-function states whereas a specialized shader can only handle a single state. Thus whereas specialized shaders have to be generated and compiled on-the-fly resulting in stutter; ubershaders can all be pre-compiled before running the game. Add to this the capability to asynchronously compile specialized shaders to replace ubershaders and the performance loss of ubershaders becomes negligible. A rare case of having your cake and eating it too.
- Sesse__ 2y agoThis is very true. And to make matters even more confusing, certain drivers were at some point capable of constant-folding shaders on-the-fly so that ubershaders are essentially moved back into a bunch of specialized shaders, negating the entire concept. I don't believe this actually affects Dolphin, though (I think the drivers in question have given up this optimization).
- MaxBarraclough 2y agoWhat's meant by top-left raster?
- sibane 2y agoThe top-left rule used in triangle rasterisation (https://en.wikipedia.org/wiki/Rasterisation#Triangle_rasterization https://en.wikipedia.org/wiki/Rasterisation#Triangle_rasteri...).
- badsectoracula 2y ago> Pray you have programmable blending I prayed for programmable blending via "blending shaders" (and FWIW programmable texture decoding via "texture shaders" - useful for custom texture format/compression, texture synthesis, etc) since i first learned about pixel shaders waay back in early 2000s. Somehow GPUs got raytracing before programmable blending when the former felt like some summer night dream and the latter just about replacing yet another fixed function block with a programmable one :-P (still waiting for texture shaders though)
- pandaman 2y agoThe mobile PowerVR GPUs had programmable blending last time I've touched those, in fact, it's the only kind of blending they had. Changing blend states on PS Vita was ~1ms, not pretty.
- pjmlp 2y agoWell, there is mesh shaders, work graphs, CUDA, plain C++ shaders. OTOY does all their rendering with compute nowadays.
- dagmx 2y agoMobile GPUs with any PowerVR heritage have it https://medium.com/pocket-gems/programmable-blending-on-ios-and-android-46bd8534076e https://medium.com/pocket-gems/programmable-blending-on-ios-... https://developer.apple.com/videos/play/tech-talks/605 https://developer.apple.com/videos/play/tech-talks/605
- Cieric 2y agoI mean most of that could be emulated in vulkan or dx12, I'm not sure about other apis. I'm curious what the use case would be though. I'm also fairly certain it can be done to a degree, but without a convincing use case it's hard to justify the implementation work.
- mandarax8 2y agoIsn't 'VK_EXT_fragment_shader_interlock' kind of like programmable blending? Or Raster-order-views in DX land. This is a great example of using it: https://vulkan.org/user/pages/09.events/vulkanised-2024/vulkanised-2024-erfan-ahmadi-devsh-with-notes.pdf https://vulkan.org/user/pages/09.events/vulkanised-2024/vulk...
- xgkickt 2y agoMy favorite part of the GS was the sheer insanity of the bus, 2560 bits wide in total with a clever split on the cache. The PS3 felt like a step down in some ways, blending especially.