This isn't software rendering, it's called turning off spatial anti-aliasing. You can still do that in the modernest of modern games. Software rendering went out of the window because the CPU tends to have other things to do whilst playing the game besides only multiplying 4x4 matrices, which was shifted to the shader cores of GPUs. The look-and-feel that the author is discussing including shadow and texture LUTs can also be done on GPUs by passing the tables in to shaders as constant read-only storage buffers; that is not specific to software rendering. It bears mentioning that many modern software renderers (LLVMpipe/Lavapipe, OpenSWR, WARP) are basically full D3D/OpenGL/Vulkan devices in their own right, including shader compilers.
Also, modern spatial anti-aliasing works by multisampling within a pixel (or even neighbouring pixels) and taking the average, rather than filtering across singly-sampled pixels, which massively reduces the quality. Not to mention temporal and machine learning AA techniques including DLSS, XeSS, FSR, and all the TAA implementations in many games.
TAA has a pretty bad reputation among many gamers for being too blurry. TSR (temporal super resolution) is a newer implementation that's overall sharper, better at eliminating "jaggies", and performant, without visible ghosting or artifacting.
Indeed. Personally I am quite old-school, I like MSAA (despite the performance hit) and subpixel morphological AA (SMAA, used to great effect in Crysis). DLSS is interesting but I cannot unsee the artifacts.
TAA is a nightmare, and Unreal Engine depends way too much on it. TSR also suffer from ghosting and artifacts unfortunately.
But I have come to the realisation that gaming will be about massive compromises for the next decade.
In a software-rendered game, the CPU draws every pixel. There’s no 3D card involved: the game works out each frame in its own code and writes it straight to video memory
I think that’s the standard definition. If you mean that this style can be achieved with graphics hardware then that’s a different argument and why your first sentence is deemed contentious
> If you mean that this style can be achieved with graphics hardware
I really ought to have been more specific with my first sentence to ward off any hair-splitting.
The author claimed to love software rendering, but the examples given to highlight the supposed positives of software rendering can all be achieved on GPUs. If the author had instead highlighted the ability to easily debug and inspect the inner workings of the rasterisation pipeline with a software renderer, that might have been a much more relevant argument.
How is it not software rendering? These games shipped without hardware renderers. Yes, they also don't have AA, but how does that make it not software rendering?
"Nothing to do" is a bit strong. It has something to do, and the explanation is in the history of how these games worked.
Can it be simulated on GPUs? Sure. But it was typical of software renderers of that era, and NOT typical of GPUs, and it has to do with how they were used.
"Software rendering went out of the window because the CPU tends to have other things to do besides just multiply 4x4 matrices, which was shifted to the shader cores of GPUs."
Hardware rendering took over because generating a 3D scene is embarrassingly parallel, and the industry quickly learned that you can have thousands of reasonably simple "cores" that can divide and conquer a scene in parallel. There was a no way a general purpose CPU could keep up.
Not so quickly. The shader cores were a breakthrough from early 2000s. First consumer GPUs were built as same as the 1980s GPUs but everything had been integrated in a single chip.
It is the sheer amount of compute and memory bandwidth that mogs a CPU but the parallel processing doesn't help much, at least in realistic 3D: an 8 core AVX-512 march CPU has an order of magnitude more SIMD lanes than something like RSX in PS3 yet it still wouldn't be able to match it's performance in rendering textured z-buffered triangles.
I'm going to guess if you did it on the video card and simply disabled those enhancements it would be considerably more energy efficient than doing it on the CPU as well which (a) means your laptop battery lasts longer on a charge, and (b) also opens up the possibility of not needing a particularly powerful CPU in order to juice the resolution, because the video hardware is doing the work for you.
From a programming perspective I do completely get the desire to have the CPU do all the work though - if you want absolutely everything under your control it's easier, and especially if your game is single-threaded.
I've mentioned this elsewhere, but nowadays, anything you see out of an HDMI/DP/eDP cable comes out of a GPU. Modern OSs make it impossible to do 'software rendering' any more; it's just that much faster and that much more efficient, even if it is harder to program directly. Even IPMI BMCs have a tiny GPU doing stuff.
It's also because at this point the operating systems themselves use the accelerated graphics architecture for things like window compositing, because that also turned out to be faster. And it's much easier to do cute little visual effects like wiggles and window distorts if those entities are actually 3D rendered graphics objects.
Even the standard desktop experience is a 3D graphics application these days.
Concur. Feels like a conflation; CPU vs GPU rendering doesn't change the appearance directly. The article performs further conflations later re the OS comparison and Steam re Ion Fury etc.
It just feels wrong historically. When HL came out, people were very enthusiastic about texture filtering and the game was clearly designed with hardware rendering in mind.
I like when games use nearest, or dedicated pixel art shaders. Bilinear just looks low-effort to me, especially when it's used for whole-screen scaling! Apple's Lanczos also looks a bit disgusting to me, I can't tolerate the display scaling on iPad because of this.
In the first waves of multimedia PCs - the CPU was tasked with doing sound, networking, hard drive control, etc. - pretty much all of the cost savings came from having minimal hardware for the auxiliary components and doing it all in drivers.
A common "Trick" was to buy cards that had essentially their own processors to handle this stuff - SoundBlasters, 3Com nics, IDE drive controllers that had their own processor (hell, even up to their own OS) since that freed the CPU up for doing actual work - gaming. Even an external or other
CPUs were a bottle neck but most people didnt tax the single core machines doing most daily work (office work, browsing the web) so it was fine, but once you load up a game that needs sound, 3d, networking, disk access all at once it would start stealing clock cycles trying to do all of that in one place.
Off-loads sample mixing to the sound card. Computers of that era were slow enough that doing 44100 additions per second was expensive (IIRC quake had 8Khz samples anyway).
I think it's because adding a sound card offloaded sound processing from the CPU and it had more cycles to draw frames! Probably back when we were at like 25Mhz
The sound card took sound computation off the CPU as well. Back in the day, every aspect of the game was fighting for CPU cycles.
Way back in the day there were some very impressive (given the technology) arcade ports to things like the Apple ][. That system's audio required running an assembly function that literally touched a memory address over and over again at a specific time rate; each touch flipped the electromagnet on the speaker. So games with theme music had to time slice hanging out in the audio routine versus doing anything else.
I grew up with a copy of Moon Patrol on Apple ][c and I didn't know for years that the theme song isn't supposed to sound like it's being played through a tea kettle.
Software rendering often provided better visual effects than the GPU paths could provide at the time. A general purpose CPU can technically do any effect since the software is the pixel shader.
Programmable shader pipelines weren't a thing until Geforce 3 in 2001.
I share the same opinion as the author. That said, it's also important to remember that the display devices of the time were different than they are now and the sharp pixelated textures we see now would look a bit different on a CRT from that period. The sharp, gritty look that he (and I) admire would have been just a little fuzzier back then.
A tiny bit fuzzier but not in a way that mattered back then. If you're running a software renderer it could well have been at 320x200 and on any monitor that comes out still looking pretty much like an LCD display, with slight blending on the edges technically but still large, large pixels not being blended. Even at 640x480 there was noticeable blockiness not being blended away. Monitors were designed to be sharper than the televisions the consoles were outputting to. Software rendering at anything high enough to be blended looking was a slideshow.
Software rendering was useful for me for a long time but as a long-time gamer (from the original DOOM to Cyberpunk 2077 and beyond) I can firmly say that real-time raytraced games at 4K/60FPS with dynamic lighting, reflections, massive geometry detail, etc, all greatly enhance the experience. That said, the old DOOM aesthetic pre-Voodoo was definitely nice. The voodoo smoothing had a nice cheap feel to it, too.
The difference in performance is just so big, unless you're targeting something without a GPU, there is no world in which you would want to leave it unutilized IMO, even if you're just rendering an UI. I can do things on my slow phone in WebGL that would stutter on my desktop if I drew the pixels with the CPU.
The article says that "even a 3.3GHz quad-core Xeon “isn’t quite enough to run Shadow Warrior at full 1600 by 1200”." But we are on DOS, so I guess three cores are just not doing anything there?
That quote about Shadow Warrior doesn't pass the smell test. You're right there must be bottlenecks in the way.
The Build engine's rendering was stunningly simple (and dare I say: elegant). You could run hundreds of instances of Shadow Warrior on a single EPYC (since they mentioned Xeon) at that resolution and framerate if you rewrote the engine with modern mechanical sympathy in mind. On a modern desktop CPU it'd probably be over a hundred instances.
People, including many programmers, just don't grasp how much power we have under the hood nowadays...
Edit: my old iPhone SE, fully utilized, can produce the same GFLOPS as the Cray T3E (the one with thousands of DEC Alphas inside). This is our reality.
Quake DOS is from a year earlier to Shadow Warrior and it would get around 60fps at 320x200 on a Pentium II 266. The Xeon from that video is from 2008, and from geekbench 2 results it's ~30 times faster than the pentium. 1600x1200 is 30 times the pixels of 320x200.
Additionally Shadow Warrior used some newer rendering techniques, so it's possible they don't scale well to higher resolutions.
> Ion Fury, a Build engine game from 2019, still ships with a software renderer.
Amazing game BTW, best shooter I've played in many years. I never really got into build engine games back then, so it's not just my rose-tinted glasses, that game is a masterpiece.
Ion Fury uses a modified version of eDuke32 which can do software only rendering, and quite well, but defaults to GPU acceleration because Ion Fury uses the real time lighting.
That said, the Build Engine had software voxels in 1997. Which was pretty cool.
I love Software Rendering too! I'd add Unreal Tournament to the list of "Games worth trying", though not sure what the multiplayer scene is like nowadays.
Unreal (and Unreal Tournament), Thief, Quake II (a slight improvement over Quake), Half-Life (a great improvement over Quake), Shadow Warrior,
Any modern port of Doom supporting software rendering, Heretic, Hexen, Descent, System Shock, Homeworld.
Software renderer of Quake II has no colored lighting. It's OpenGL-only feature. Half-Life and Unreal do this better, they support colored lighting in their software mode.
I am still a big fan of CPU render for VFX (not games). It is stable, capable of very large scenes. GPU is fast but you will never render something really big. And CPU look is much much better.
> you will never render something really big. And CPU look is much much better.
Why do you believe these things? In VFX and film, the GPU shaders and rendering is identical to CPU, they use the exact same programmable shaders on either side, so there is no difference in look or capability. Today’s GPUs have out of core streaming and caching and access to host memory. Pixar showed off their pixel-matching between GPU and CPU at Siggraph this year, and mentioned that today’s consumer GPUs are big enough to render IIRC ~98% of their scenes without much ‘out-of-core’ tech. Lots of film and VFX studios are using GPUs in production today to render pretty big shots. I think your story is a bit out of date; GPUs being size limited was somewhat true in the past, but is quickly going away. The CPU vs GPU look question has never been true for VFX or film, and was only true in games if you chose different rendering algorithms.
I don’t know much about this so I’m curious. Is the reason why GPUs aren’t preferable for large scenes due to their limited VRAM or a different aspect of them?
Because the pipelines lacked fast, dedicated linear algebra engines, you saw a lot of clever hacks to get around having to do full linear algebra as well.
The original Marathon allowed you to look up and down, but it wasn't actually tilting the camera frame; it was applying a distortion on the field of view and then basically vertical scrolling the render target. Essentially, you can think of it like you were playing the game in vertical phone mode all the time but you were looking at the middle third of that possible output domain, and looking up and down pretty much just scrolled what you were looking at and applied a trapezoid transform.
This is why you couldn't look straight up or straight down, the trapezoid transform would become painfully obvious quickly and the actual algorithm did not really tilt your field of view.
But it was good enough that they could slap it on the box as a novel feature for Wolfenstein style first person shooters.
I don't think it really applies when we're talking about PC gaming. Consoles were blurry as hell on a huge interlaced low-res TV, but late-'90s PC games on a decent monitor had nice and crisp pixels on a CRT that weighed as much as a large dog. Especially when flat-glass trinitron CRTs and the like came out (yes spellcheck, that's a word), I don't think the end-user appearance on the screen was all that different from what we have now, other than obvious stuff like aspect ratio and incremental improvements to resolution and framerate. Maybe deeper blacks and lower latency on CRT.
The ability to shift resolutions natively was neat, though, I missed that in the pre-4K days.
I remember when I finally saw my favourite 3D games (Quake 2 and Pod) on a Voodoo2 and I immediately bristled: I hated the blurry way the textures looked with bilinear filtering, and was iffy on their love of yellow lighting.
I've softened on the issue of non-white lights, but I 100% am still full of nostalgia about unflitered low-res textures.
“Software rendering” usually means “doing rasterization on the CPU”, as opposed to “hardware rendering” that is done by the rasterization primitives of the GPU.
Nanite is a bit weird because it doesn't use the hardware rasterization of the GPU, but it's still doing rasterization on the GPU, so it doesn't really fit this dichotomy.
No software rendering requires DOS, you could use it with Windows back in the day (how I originally played Half Life) and engines that still support it will run on modern OSes too.
Eh, Nanite rasterisation is still happening on the GPU, it's "just" implemented in shaders rather than using the fixed-function pipeline. "Software rendering" is becoming less useful as a descriptor as graphics hardware becomes more general.
Wrote a little software rasterizer for a roguelike years back and the best part was just being able to step through the whole pipeline in a debugger. No driver weirdness, no shader compile quirks, the pixel is wrong because your math is wrong.
Yeah, that is the hardest part about 3D graphics programming, at least it was the last time I had my elbows deep in it.
You're not doing traditional application programming once you get into 3D graphics. You are driving a microcomputer at arm's length. Every aspect of that challenge comes into play, from the fact that it's a black box to how you can have it working perfectly in one configuration of hardware, and then find it doesn't work on another configuration.
My favorite reasons for this include "there is a legitimate bug in the closed-source shader compiler" and "this graphics card advertises a capability but in reality it implements it in software so if you turned that flag on your render speed suddenly went to seconds per frame."
The CUDA era helped some with this problem because there was suddenly massive pressure on making the GPU into less of a bundle of pipelines and specialty hardware accelerators strapped together and more into standardized massively parallel fabric, because card manufacturers suddenly found themselves not wanting to be left out in the cold if they invested their time in building a very very fancy specialty hardware circuit for doing texture manipulation or something... And that proved to be useless for mining Bitcoin, or whatever they suspected might replace Bitcoin in the future. I think there are far less gotchas now regarding weird architecture than there were in the 2010s.
Also, modern spatial anti-aliasing works by multisampling within a pixel (or even neighbouring pixels) and taking the average, rather than filtering across singly-sampled pixels, which massively reduces the quality. Not to mention temporal and machine learning AA techniques including DLSS, XeSS, FSR, and all the TAA implementations in many games.
I really ought to have been more specific with my first sentence to ward off any hair-splitting.
The author claimed to love software rendering, but the examples given to highlight the supposed positives of software rendering can all be achieved on GPUs. If the author had instead highlighted the ability to easily debug and inspect the inner workings of the rasterisation pipeline with a software renderer, that might have been a much more relevant argument.
Can it be simulated on GPUs? Sure. But it was typical of software renderers of that era, and NOT typical of GPUs, and it has to do with how they were used.
Hardware rendering took over because generating a 3D scene is embarrassingly parallel, and the industry quickly learned that you can have thousands of reasonably simple "cores" that can divide and conquer a scene in parallel. There was a no way a general purpose CPU could keep up.
It is the sheer amount of compute and memory bandwidth that mogs a CPU but the parallel processing doesn't help much, at least in realistic 3D: an 8 core AVX-512 march CPU has an order of magnitude more SIMD lanes than something like RSX in PS3 yet it still wouldn't be able to match it's performance in rendering textured z-buffered triangles.
> "3D cards smoothed textures with bilinear filtering"
You can just not do that.
From a programming perspective I do completely get the desire to have the CPU do all the work though - if you want absolutely everything under your control it's easier, and especially if your game is single-threaded.
Even the standard desktop experience is a 3D graphics application these days.
[1]: https://news.ycombinator.com/item?id=44966266
A common "Trick" was to buy cards that had essentially their own processors to handle this stuff - SoundBlasters, 3Com nics, IDE drive controllers that had their own processor (hell, even up to their own OS) since that freed the CPU up for doing actual work - gaming. Even an external or other
CPUs were a bottle neck but most people didnt tax the single core machines doing most daily work (office work, browsing the web) so it was fine, but once you load up a game that needs sound, 3d, networking, disk access all at once it would start stealing clock cycles trying to do all of that in one place.
Way back in the day there were some very impressive (given the technology) arcade ports to things like the Apple ][. That system's audio required running an assembly function that literally touched a memory address over and over again at a specific time rate; each touch flipped the electromagnet on the speaker. So games with theme music had to time slice hanging out in the audio routine versus doing anything else.
I grew up with a copy of Moon Patrol on Apple ][c and I didn't know for years that the theme song isn't supposed to sound like it's being played through a tea kettle.
Programmable shader pipelines weren't a thing until Geforce 3 in 2001.
The Build engine's rendering was stunningly simple (and dare I say: elegant). You could run hundreds of instances of Shadow Warrior on a single EPYC (since they mentioned Xeon) at that resolution and framerate if you rewrote the engine with modern mechanical sympathy in mind. On a modern desktop CPU it'd probably be over a hundred instances.
People, including many programmers, just don't grasp how much power we have under the hood nowadays...
Edit: my old iPhone SE, fully utilized, can produce the same GFLOPS as the Cray T3E (the one with thousands of DEC Alphas inside). This is our reality.
Additionally Shadow Warrior used some newer rendering techniques, so it's possible they don't scale well to higher resolutions.
Sources: * https://framebuffer.io/project/quake * https://browser.geekbench.com/geekbench2/327940 * https://browser.geekbench.com/geekbench2/529270
Amazing game BTW, best shooter I've played in many years. I never really got into build engine games back then, so it's not just my rose-tinted glasses, that game is a masterpiece.
That said, the Build Engine had software voxels in 1997. Which was pretty cool.
I can add more:
Unreal (and Unreal Tournament), Thief, Quake II (a slight improvement over Quake), Half-Life (a great improvement over Quake), Shadow Warrior, Any modern port of Doom supporting software rendering, Heretic, Hexen, Descent, System Shock, Homeworld.
That colored lighting, though.
Why do you believe these things? In VFX and film, the GPU shaders and rendering is identical to CPU, they use the exact same programmable shaders on either side, so there is no difference in look or capability. Today’s GPUs have out of core streaming and caching and access to host memory. Pixar showed off their pixel-matching between GPU and CPU at Siggraph this year, and mentioned that today’s consumer GPUs are big enough to render IIRC ~98% of their scenes without much ‘out-of-core’ tech. Lots of film and VFX studios are using GPUs in production today to render pretty big shots. I think your story is a bit out of date; GPUs being size limited was somewhat true in the past, but is quickly going away. The CPU vs GPU look question has never been true for VFX or film, and was only true in games if you chose different rendering algorithms.
The original Marathon allowed you to look up and down, but it wasn't actually tilting the camera frame; it was applying a distortion on the field of view and then basically vertical scrolling the render target. Essentially, you can think of it like you were playing the game in vertical phone mode all the time but you were looking at the middle third of that possible output domain, and looking up and down pretty much just scrolled what you were looking at and applied a trapezoid transform.
This is why you couldn't look straight up or straight down, the trapezoid transform would become painfully obvious quickly and the actual algorithm did not really tilt your field of view.
But it was good enough that they could slap it on the box as a novel feature for Wolfenstein style first person shooters.
(And I actually do like their sound, but I wouldn't want to be stuck with only tubes)
Now that will truly blow his mind, at least on this setup and older games.
The ability to shift resolutions natively was neat, though, I missed that in the pre-4K days.
I've softened on the issue of non-white lights, but I 100% am still full of nostalgia about unflitered low-res textures.
Nanite is a bit weird because it doesn't use the hardware rasterization of the GPU, but it's still doing rasterization on the GPU, so it doesn't really fit this dichotomy.
A mix of software and gpu
You're not doing traditional application programming once you get into 3D graphics. You are driving a microcomputer at arm's length. Every aspect of that challenge comes into play, from the fact that it's a black box to how you can have it working perfectly in one configuration of hardware, and then find it doesn't work on another configuration.
My favorite reasons for this include "there is a legitimate bug in the closed-source shader compiler" and "this graphics card advertises a capability but in reality it implements it in software so if you turned that flag on your render speed suddenly went to seconds per frame."
The CUDA era helped some with this problem because there was suddenly massive pressure on making the GPU into less of a bundle of pipelines and specialty hardware accelerators strapped together and more into standardized massively parallel fabric, because card manufacturers suddenly found themselves not wanting to be left out in the cold if they invested their time in building a very very fancy specialty hardware circuit for doing texture manipulation or something... And that proved to be useless for mining Bitcoin, or whatever they suspected might replace Bitcoin in the future. I think there are far less gotchas now regarding weird architecture than there were in the 2010s.