I 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.
TI 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."
Yep, and I think perhaps that’s where folks are getting hung up.
NVIDIA didn’t invent the GPU. They coined the modern term “graphics processing unit”. Prior to that, various hardware existed but went by other expanded names or don’t fully match NVIDIAs arbitrary definition, which is what we use today.
basically with all those bells and whistles (transform, lighting, clipping, shaders, etc, etc)
the "old way" was to engineer a bit of silicon for each one of those things, custom-like. problem was how much silicon to give to teach feature, it almost has to be fine-tuned to each individual game, a problem
So nvidia comes up with the idea to sort of have a pool of generic compute units, each of which can do T&L, or shading, etc. Now the problem of fine-tuning to a game is solved. but also now you have a mini compute array that can do math fast, a general-purpose unit of processing (GPU-OP), which was a nod from NVIDIA to the gaming community (OP - overpowered)
I think I remember seeing the term GPU used in a Byte article from the 80s? It was a while ago when I saw it (~15 years), so I can't really remember any details.
That seems to be what I remembered. I did try a few searches; But I didn't find it in the first few results of "byte magazine gpu" on Google, and my search on IA wasn't completing. I didn't feel like spending more time than that...
> Two years later, Nvidia introduced the GPU. He [Curtis Priem] recalls that
> Dan Vivoli, Nvidia's marketing person, came up with the term GPU, for
> graphics processing. "I thought that was very arrogant of him because how
> dare this little company take on Intel, which had the CPU," he said.
Among 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.
> 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.
That's kinda overselling it, honestly. When you're talking about the GIF, only the VU1's vertex pipeline was able to achieve this speed directly. PATH2/PATH3 used the commodity RDRAM's bus (unless you utilized MFIFO to mirror a small portion of that to the buffer, which was much more difficult and underutilized than otherwise since it was likely to stall the other pipelines); the exact same bus Pentium 4's would use a few months after the PS2's initial launch (3.2-6.4GB/s). It's more akin to a (very large) 4M chip cache, than proper RAM/VRAM.
As to the PS3 being half that, that's more a design decision of the PS3. They built the machine around a universal bus (XDR) versus using bespoke interconnects. If you look at the Xbox 360, they designed a chip hierarchy similar to the PS2 architecture; with their 10MB EDRAM (at 64GB/s) for GPU specific operations.
As to those speeds being unique. That bandwidth was made possible via eDRAM (on-chip memory). Other bespoke designs utilized eDRAM, and the POWER4 (released around the same time) had per-chip 1.5M L2 cache running at over double that bandwidth (100GB/s). It also was able to communicate chip-to-chip (up to 4x4 SMP) at 40GB/s and communicate with it's L3 at 44GB/s (both, off-chip buses). So other hardware was definitely achieving similar to and greater bandwidths, it just wasn't happening on home PCs.
I think that’s fair. It was, in effect, a cache and DMA target. A similar scheme was present in the Cell, where the SPE’s had 256KB of embedded SRAM that really needed to be addressed via DMA to not drag performance to the ground. For low-level optimization junkies, it was an absolute playground of traps and gotchas.
Edit: if memory serves, SPE DMA list bandwidth was just north of 200GB/s. Good times.
Growing up with the tech press in this era, “commodity RDRAM” is a funny phrase to read!
As I recall, the partnership between Intel and Rambus was pilloried as an attempt to re-proprieterize the PC RAM interface in a similar vein to IBM’s microchannel bus.
It wasn’t a commodity! It was a single-owner proprietary technology. You needed a license from Rambus to manufacture it. And at least at the time it commanded a premium price over true commodity DRAM.
People on Slashdot got really worked up when Intel signed a deal with Rambus to make RDRAM the only supported technology on Intel x86—from which they relatively quickly backtracked.
Anandtech (sniff) of course has great contemporary background:
PS2 compatibility on PS3 went through 3 phases. Launch models had EE+GS+RDRAM (full PS2 hardware), just after had only GS, and finally emulation was done entirely in software. Using a CFW can utilize the latest method to play most (ISO backed-up) PS2 games.
Sure and actually if available that is the default when mounting ISO. Just saying essentially every PS3 can emulate PS2 games. Not only those with (full or partial) PS2 hardware. Worth mentioning PSN classics (or converted games) utilize software emulation in every PS3.
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.
I heard something similar with Jak and Daxter, where they took advantage of the embedded PS1 hardware on the PS2 to scrape together some extra performance.
Most PS2 games used the PS1 hardware for audio/sfx so you freed the main CPU for rendering/gameplay.
I believe Gran Tourismo 3 used the ps1 hardware for everything except rendering, which was the kind of nuts thing you could do if your games were single platform and with huge budget.
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).
Definitely 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.
Most games were primarily C. 3D performance came from the graphics hardware, which had straightforward C APIs and dedicated texture RAM. The machine lacked a floating point processor, so I think we wrote some fixed point math routines in assembly, but that's basically it.
PS1 is famous among game developers for being the first games console for the home market with a C SDK, instead of only Assembly as programming option.
All games tap into Assembly, in some form or the other, even nowadays.
Would programmers now be able to make God of War 2, FF12, Jak 2&3 and Ratchet and Clank 3&Deadlocked? PS2, slim especially, is an incredible machine. Scale the games up to 1080p or 1440/4k and they look great still.
It’s hard to compare memory bandwidth of these systems because of the various differences (e.g. different RAM types). I know that the theoretical RAM bandwidth for the N64 is way higher than what you can practically achieve under typical conditions.
I totally agree, except when it comes to emulation. It is immensely hard to real-time emulate if some facet of your host hardware isn’t at least a little bit faster than the corresponding element in the emulated system. Then you have to lift the abstraction and often find that the rest of the system reflects this specificity.
At my last job, we had ASICs that allowed for single-sample audio latency with basic mixing/accumulation functions for pulling channels of audio off of a bus. It would have been tragically expensive to reproduce that in software, and the required hardware to support a pure software version of that would have been ridiculous.
We ended up launching a new platform with a different underlying architecture that made very different choices.
Most third parties weren't able to explore the PS2 properly, until Sony had to go through a revamp of their SDK, and collaborated with Gran Turism folks to show what was actually possible.
Not sure what you mean. The entire system was available to everyone day 1 through the manuals. The introduction of the VLC VU assembler made VU development easier (single instruction stream, automatic register allocation). PATH3 texture uploads maybe?
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.
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
The 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.
I 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.
> 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?
My (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.
(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
My 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.
Basically, 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.
> 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.
This 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).
