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.
A 16(!!!) bit ISA slot card, which revolutionized PC-audio-experience.
Are they still on the market or crashed by the ever-more-increasing onboard chips?
And there was Gravis Ultrasound, where you could upload samples into the RAM of the soundboard (that was like superpowermegatech back at these days :-)
IIRC, the highest degree of fidelity was fu**ng 16 MB of onboard RAM on the soundboard.
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
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).
Something that always seems to surprise me when I remember it today: Playing an MP3 on my Pentium CPU in 1996 worked, but it _really_ brought the system to its knees. I could choose between listening to MP3 music or interacting with some other program (mIRC, Netscape, etc) but certainly not both.
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.
CPUs from that era were single core and pretty slow. They had to do everything like game logic, graphics, sound, etc all at once, so it was often resource starved. Sound took some resources, sometimes significant depending on the sound and what else the cpu was doing, unless it was a really simple sound (think NES style sound). Moving that to a dedicated sound card meant the cpu didn't have to worry about sound anymore.
Sound, like a lot of things, could be seen as a peripheral and a lot of peripherals back then needed their own cpu to perform well. One interesting fact I recently learned is the commodore 64 was so resource starved, the external floppy drive you could buy had its own 6502, just like the C64 did as its main processor. It just had to off-load that to another cpu because its own cpu was too busy to reliably run a disk drive. There are other reasons for this like commodore's experience in drives previously was this kind of architecture so they went with what they knew, but its a bit interesting to know your floppy drive was essentially another C64 with its own commodore OS and ram and 6502.
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.
Why is it “impossible”?
If you mean that a rendered frame has to reside in the graphics memory before being sent to the display, then I think that was the case even when software rendering was a thing.
If you mean rendering a frame entirely in the main memory by the CPU, then there is nothing making it impossible. I mean, most major 3D rendering software still have CPU renderers as an option. Slow, but doable.
P.S: I am using offline renderers here as an extreme example. A game renderer - especially for scenes like Quake’s - are definitely going to be far simpler and cheaper.
By 'impossible', I mean it in a very strict sense of blitting full-screen frames directly into the framebuffers provided by HDMI or (e)DP representing a visible surface. This is still kind of possible in Windows when games are properly full screen and not 'borderless full screen', but the OS still does compositing in the background, and the GPU is still involved to some extent.
Of course, offline rendering is a different story.
Using the extra unpopulated memory slots on your VGA card to get that 1024x786 at 256 colors. 800x600 is the largest which will fit in 512k of video memory at that colors depth, or getting 16bit color space in 800x600 due to having doubled your memory from 512k to 1024k. And those were definately the software rendering days, every ramdac needs it's own memory pool.
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.
makes me wonder how would gameplay fare when a gpu renders the game with very limited options. Sometimes higher FPS would play weirdly with the physics engine and some moves you could do when capped at 24fps were not possible at 60fps.
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.
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.
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.
He likes the look of nearest neighbor texture sampling, not software rendering.
You can do nearest neighbor in hardware rendering and you can do bilinear in software rendering. Rendering mode and texture sampling are two totally different things.
I think there's more to it. In Quake, the software renderer decides the color of each pixel, based on running some code on the CPU, which can do anything. GPU rasterization is far more standardized, with standards defining how each triangle ought to be sampled at each pixel coordinate (and the fact that you're sampling triangles in the first place).
The whole process is standardized with GPU rendering, leading to ways of rendering and content authoring that's quite different from how things used to be, and while definitely possible, modern 'retro' games often render like GPU accelerated games and just disable texture filtering, which doesn't quite give you the look.
He mentions Build games, which are not strictly polygonal.
While general purpose computation exists on GPUs, and the standard rasterization pipeline can be implemented in software, graphics cards have pushed people towards a 'look and feel' which comes partly from standardized data structures, content authoring and rendering approaches, that have made games feel samey.
Whereas with software rendering, essentially you have an array of pixels which you can set to a certain color, and the rest is up to you, which made devs come up with unique ways of rendering and authoring content.
The intricate level designs that were made possible with BSP based tools and are basically 'free' to render in software, had hell of a time making the transition to GPUs, as they rely on traversing the tree while drawing pixels, whereas for the GPU, you need to submit a list of triangles (unless you go GPGPU)
Modern games look samey because they all want the same result - photorealism - and aren't fussy about using an off-the-shelf solution - i.e. UE5 and Unity. We have absolutely insane levels of control over the rendering pipeline and almost everything is programmable; the GPU is an endless fountain of parallel programming. But in order to take advantage of any of that you have to actually start changing engine code, or write your own renderer, and games don't care because the default UE5 look is "good enough".
There is some standardization in that, if you issue geometry and sample textures normally, you will be relying on hardware units for rasterization and texture sampling, and those do have a relatively limited set of options for how they work. However, those options encompass most if not all of what 3D engines could ever want or need, even the early 3D ones that had all sorts of hacks. The kinds of things GPUs can't actually rasterize in hardware are things like NURBS or metaballs, but this doesn't matter because the industry settled on triangles[0] as the medium of real-time 3D really early on.
A lot of the look of old 3D games comes down to them doing things the lazy way, and I'm proud to say the lazy way is still very much supported - so long as you turn off features that didn't exist later on and limit yourself. I'm not as familiar with old DOS games, so I'll use the PS1 as an example. The "PS1 look" is very much a result of its incredibly limited rasterizer, whose limitations can be trivially emulated in modern hardware:
1. Don't allocate or bind a depth buffer. You will need to Z-sort your geometry every frame. Part of the "PS1 look" is that some games did it wrong; if you do it correctly you'll be burning performance for no visual benefit. Pick a scheme that breaks in a visually interesting way. Likewise make sure to not allocate any multisampling since the PS1 didn't anti-alias either.
2. Restrict the precision of vertices in your vertex shader by rounding them. The PS1 did vertex math with incredibly low precision and it makes vertices wobble.
3. Restrict the precision of UVs in your fragment shader. PS1 UVs were 0-255, so you want 1/256 precision.
4. Aggressively discard geometry that clips the edge of the viewport. The PS1 did not have proper polygon clipping; you just couldn't render off the end of the viewport, so games had to discard geometry and subdivide polygons to avoid things disappearing. This is another "if you do it well, nobody will notice" thing.
5. Turn off perspective-correct attribute interpolation; this will make your UVs warp and distort at certain angles. You do this with the `noperspective` attribute in GLSL.
6. Disable bilinear filtering when sampling textures.
7. Allocate and render to a low-precision color buffer. Lots of games would change the color depth to match the available VRAM. This is probably the hardest aspect to emulate unless you are actively counting VRAM usage and sticking to realistic values.
8. Bitcrush your textures before uploading them. The same reasoning applies here. Also, don't upload any mipmaps.
9. Lighting was done through vertex colors, which were calculated on the CPU. You don't have to limit yourself to CPU lighting but you do have to make sure lighting is done in the vertex shader.
10. Optional: implement the early model PS1 texture banding bug in your fragment shader.
This will give you a rendering pipeline that is good for basically all purposes except bit-accurate PS1 emulation. Of course, if you were doing bit-accurate emulation, nothing stops you from issuing a screen-filling quad and writing a GPU shader that does software rasterization on the GPU. Or launching a compute shader that accesses the framebuffer arbitrarily - although you do have to worry about memory coherency across warps and workgroups. Texture sampling can also be done "in software" if you so wish - i.e. by doing unfiltered reads to the texture which are glorified array lookups, and then filtering those reads as you wish.
[0] There was a brief moment where quads might have been able to win - artists like to work with them, and Nvidia was shipping quad hardware. But the advantage died very quickly, and quads can be easily converted to triangles - not so much the other way around.
Technically you're right, a gpu is just a bunch of ALU and FPU in a way, we just defer computation to a massive array of them so the cpu can do other things, what you do on these gpu cores is up to you.
That said, historically, software rendering meant non-accelerated passes that could be carried out by a cpu at decent enough FPS.
ps: some could also say that a FPU is not software rendering since early x86 didn't have it in the cpu.
But if you want to experience GLQuake that looks like software-rendered Quake, that's a simple settings change in your GPU driver, overriding the texture sampling mode. That's literally the only difference. I'm not sure the author is aware that it is a viable option to tweak the hardware rendering this way.
> if you want to experience GLQuake that looks like software-rendered Quake, that's a simple settings change in your GPU driver, overriding the texture sampling mode. That's literally the only difference.
Is that the case?
https://fabiensanglard.net/3dfx_sst1/ has a side-by-side screenshot comparison of the two, and software Quake's colours and lighting look way more rich and vibrant; it's not just smoother textures. It's possible that GLQuake/one of the many source ports since has improved on this though.
Of course I know this is a particular quality of GLQuake and not an actual limitation of hardware rendering. And I agree with in general with the contention that this article is talking about a particular art style associated with mid 90s software rasterizers rather than about "software rendering" itself.
In the caption under the image it explains that the 3Dfx card lacked gamma correction, which is why it looked so saturated. The Voodoo was a pass-through card: it had its own DAC for generating display signal when a full screen 3D game was running, but otherwise your 2D accelerator was used. So on the same machine a software rendered game and a 3D accelerated game had different output even if the frame buffer was identical, due to different circuitry (and the Voodoo card’s circuitry lacking gamma correction made it hella saturated as you see here).
This could have been corrected on the art side, by recalibrating the texture maps to the voodoo gamma levels, and that’s why there are great arcade machines from that era with wonderful graphics (designed for the hardware they were running in production), but GLQuake looks all washed out.
Are you sure? I haven't played enough Quake to know either way, but I did play Deus Ex in software mode (unreal engine), and that had a lot of differences to the other renderers. I very much doubt texture sampling mode alone would reach a similar result.
(It even had graphic errors, green textures in the faces etc giving everything a very alien look. But that's not what I mean).
May be a couple settings. IIRC full bright textures didn't translate well in early GPU renderers. Often they'd appear shaded as if they weren't light sources at all.
I agree with you and I think others aren't understanding your point. "Hardware rendering" can also be achieved by the CPU in "software". It will just not be realtime. Just fire up Blender and render scenes using the CPU, which is a standard option. You will see how amazing "software" rendering can be.
There's nothing special about the GPU besides doing certain kind of operations that are very useful for graphics (and AI, among other things) really efficiently. The distinction should never have been "software rendering" vs "hardware rendering", but "what CPU rendering could achieve when GPUs weren't widespread" versus "what GPU rendering has been able to achieve since they became available".
This is fine, but then we'd also have to specify your CPU performance constraints. If you max out a modern CPU for CPU rendering, you will get graphics vastly exceeding what 80s/90s CPU rendering could achieve.
Not necessarily. Someone unfamiliar with graphics might believe that there’s something about a CPU that a graphics card doesn’t have such that the look can’t be achieved. Certainly the author of this piece seems to believe that.
What they meant was: "This aesthetic isn't exclusive to software rendering". I thought the rest of their comment made that pretty clear once you got past the first sentence.
I think the issue is that modern aliasing can be done without a GPU, so it's not that he loves software rendering, it's that he loves the style the constraints of the time imposed, and that style is not married to CPU-exclusive rendering.
Real players know you us the coarsest mipmap level the whole time, so every texture is something like 4 pixels. And 320x200 and directmouse. It's the smooth movement, high fps and direct control that provides the sense of "being there". Not the graphical fidelity.
I think you've almost exactly described my Counter-Strike setup 25 years ago.
Friends at LAN parties complained how ugly it was and my rebuttal was usually: "I'm afraid it stays unless you can buy me a better video card." The fact that the CRT slowly drifted to a yellow tinge on everything didn't help the asethetics--especially on de_dust. The GPU at the time might have been a Riva 128 ZX.
Of course you can but I think author’s point is to actually test/evaluate maximum performance of true software rendering on modern machines, and this is fine and refreshing exercise, even with filtering.
It’s 100% software rendering on CPU just multithreaded. But no metal/direct3d just framebuffer and rest is yours routines… and I actually added bilinear filtering…
Still fun project to do and remind yourself about fundamental algorithms behind elementary 3D graphics
Yeah, when glquake and the Voodoo1 came out, I was actually initially disappointed because I'd seen demos of vquake on the verite and its texture mapping was closer to the original. But you couldn't complain about the framerate of the 3dfx.
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?
Here’s an analogy. Suppose someone said, “I love manual transmission cars” and then described in detail the physical knobs and dials that all the cars from the 1950s had.
It turns out what they like is physical knobs and dials. You can have those in automatic transmission cars. It so happens that most modern automatics also have shitty touchscreens.
(I know this analogy isn’t precise because there was a long period of automatics with physical controls, but bear with me.)
The point is that there’s nothing _inherent_ to software rendering that’s responsible for the thing he likes. The distinction is useful because, for example, he could go seek out modern games with the look he likes. Or make games. And if he thought the thing he likes comes from having a software renderer, he’d leave a lot of performance and power efficiency on the table for no good reason. He likes a certain rendering style that’s equally achievable with both GPU and CPU rendering. The choice of hardware should probably be driven by considerations like performance, debuggability, platform support, availability of libraries, etc.
Ah, I see. Maybe: somebody says they love audio cassette players, and start talking about the super tactile mechanical buttons and switches that go chunk in a satisfying way. You could rightly object that that you can put buttons like that on an mp3 player. But it's a historical fact that these things are actually linked, in a way that's meaningful to people, namely in their personal nostalgic experiences.
"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.
This is incorrect. It is exactly the same algorithm as circuits in the GPU or as instructions on the CPU. No difference, except one: the way data is pipelined on the GPU makes texture blending free, or nearly so. So to show off, every 3D game back then turned it on (an OpenGL/Glide/D3D configuration option) and everything got smoothed out, often with no option to turn it off. That's why it ends up looking different: because the game itself selected different interpolation in accelerated vs software rendered. It was a game choice.
These days you can use different presets to override those choices, and have your 8K, 240Hz Quake look software rasterized, if you want.
Incorrect how? It's correct in that software renderers of the time TFA describes mostly looked like this, and GPU renderers didn't (of course, they weren't called GPUs back then), and there's a reason for this. Even you admit it later in your comment.
So saying "it has nothing to do" with software renderers (of the time) is wrong. It has something to do with how software renderers vs GPUs were used during that era in practice. It's also true you can simulate one with the other, but that doesn't make it incorrect or unrelated.
> So to show off, every 3D game back then turned it on (an OpenGL/Glide/D3D configuration option) and everything got smoothed out, often with no option to turn it off. That's why it ends up looking different
So it had something to do after all! So TFA has a point. He means software renderers in the sense you're describing here, and it's clear from the text. He's not implying you cannot use a GPU to achieve the same result.
Software renderers can do bilinear filtering. It does not change any aspect of how the software renderer works. I’ve implemented this, so I know: it’s a couple of lines change in the texture lookup. But it adds three lerps per channel, per pixel, whereas nearest neighbor requires none. That’s 9 multiply-adds in the tightest inner loop that would normally have zero. In the 3D accelerators of the era, the pipelines were all fixed-function (programmability is why NVIDIA renamed it GPU when they released the GeForce 256), so those lerps were in the silicon whether you used them or not. Bilinear filtering had zero impact on render speed, so long as you weren’t saturating video RAM with the added texture lookups.
TL;DR a software rendered game and a 3D accelerated game from that era looked VERY different, but that difference was largely down to a feature that was often implemented in the software renderer, and was only a couple of lines in the innermost loop. But rarely used outside of a few choice effects due to the massive performance impacts. On 3D accelerators it was free, and default-on.
(I’m an old fart that cut my teeth in programming writing software renderers with the community at Flipcode, if anyone remembers that.)
I'm not disputing the technical details of anything you're saying. I don't think the author of TFA is, either.
So when you say "this is incorrect", and also:
> Software renderers can do bilinear filtering.
What do you mean? Nobody is disputing they can. The author is talking, in my opinion, about how software and hardware renderers of that time behaved in practice in games you could buy at the time. It's just that peppering the text with "at the time", "typical" and "in practice" makes for very cumbersome reading.
I'm also an old fart, by the way :) I don't remember Flipcode, but I wrote software renderers for fun and also for my CS coursework. I read my Abrash and my Foley & van Dam, etc. I then lost track of that, time was finite and I had to choose my hobbies more carefully!
This is ridiculous. He explained it perfectly and he was right stating that it has "nothing to do with software rendering". The fact that people specifically chose to do it differently on hardware makes nothing about what the article mentions specific to software rendering. Otherwise if you do the smoothing on the CPU you have to call it a hardware renderer now to be consistent.
It's not ridiculous. It's also perfectly clear from TFA, one has to go out of their way to misinterpret this.
E.g.
> Software renderers generally sample textures pixel by pixel, so every texel stays a crisp square. Early 3D cards smoothed textures with bilinear filtering, which looked impressive in 1997 but turns everything soft and blurry to my eye now.
The author is a hobbyist discussing things in context. Early 3D cards, bilinear filtering as done in '97, etc. You cannot take random words and criticize the article. This seems to be a retrogaming hobbyist blog about doing stuff with old hardware and games.
The point is that the look is not inherent to software rendering. You're misinterpreting this as some kind of denial of historical association.
You're own quote there identifies texture filtering as the difference. Explaining that you can get those sharp textures with hardware acceleration, isn’t “pointless nitpicking.”
"Software" isn't the point. You can do the exact same math on CPU or GPU. OpenGL supports nearest neighbor texture filtering on whatever hardware you run it on since 1992, one year before Doom even came out.
But in practice, this didn't happen, which is what TFA seems to be all about. So it's not incorrect to talk about software renderers (of the time) vs hardware accelerated graphics (of the time) and how they were used in practice (at the time). It's just cumbersome to write "at the time", and it's understood from context; at least I did. It also helps to look at the rest of the blog's articles and what the blog is about...
I isn't "simulated" by GPUs, it is a rendering mode that GPUs had since before they were called GPUs.
The reason software rendering look different from 3D accelerated games (incl. 3Dfx) is nearest neighbor filtering and low resolution, which were necessary to keep a reasonable framerate. At the time, it was considered ugly, so if your hardware supported bilinear filtering for free, it was turned on, but it didn't have to.
In the time of fixed pipelines (3Dfx to GeForce 3), you couldn't do arbitrary operations on pixels, so some effects, like the kind that are common in the demoscene were software only. So games that used these effects, like Comanche voxels can indeed be thought as representative of software rendering, and they can, of course, be simulated on modern GPUs as everything that was done on software before can.
But the article uses Quake as an example. I may be wrong, but I don't think it does anything that can't be done by a fixed pipeline GPU. In fact, even keeping the same style (nearest neighbor filtering + low resolution), hardware rendering will probably look better because the GPU does proper perspective correction on every pixel. The tricks used by the Quake engine are awesome, but they don't beat raw power.
> I isn't "simulated" by GPUs, it is a rendering mode that GPUs had since before they were called GPUs.
Yes, of course. That's what I meant. I didn't mean "simulate" as in fake, I meant it more as in "replicate the same effect". Ultimately, hardware and software are equivalent, give or take matters of costs, debugging and performance.
> In the time of fixed pipelines (3Dfx to GeForce 3), you couldn't do arbitrary operations on pixels, so some effects, like the kind that are common in the demoscene were software only. So games that used these effects, like Comanche voxels can indeed be thought as representative of software rendering, and they can, of course, be simulated on modern GPUs as everything that was done on software before can.
Yes, I think that's the spirit in which TFA's term "software rendering" must be taken. The context is old games and their pipelines as they were used at the time, not more recent GPUs or practices.
> The tricks used by the Quake engine are awesome, but they don't beat raw power.
I really don't think the article is contesting this.
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.
"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 its performance in rendering textured z-buffered triangles. 3D graphics can really go wide only on wireframe/points, z-buffer forces sequencing between polys so the parallelism there is very limited.
Parallel processing was fully in force in the very first GPUs, like the Voodoo. Not like a modern GPU with thousands of more flexible shader cores, but the first iteration had a pipeline architecture that saw multiple blocks operating on rendering separate parts of the pipeline in parallel. This was revolutionary. Especially given that CPUs at the time had a single core.
I'm not sure what the PS3 comparison is for, or why we're comparing a 2026 AVX-512 CPU with a 2006 gaming console. Okay? A modern GPU can obliterate any CPU in SIMD, presuming you conform with the types it wants. Add that it's weird to bring up as AVX and other SIMD techniques are basically the same sort of architecture, parallelizing a problem.
> 3D graphics can really go wide only on wireframe/points, z-buffer forces sequencing between polys so the parallelism there is very limited.
Rendering a 3D is scene is the very definition of embarrassingly parallel. While optimizers can cull the scene, you know that the entire depth within the frustum (there are a variety of optimizing techniques to minimize the overdraw, but it's a part of rendering a scene) is "rendered" and in amalgamation the Z-buffer values are compared and discarded, blended, or whatever? It is an extraordinarily parallel operation.
Voodoo Graphics came out in 1995, we had commercial GPUs since early 1980s. Also it's funny that you believe it was "full force" parallel because specifically Voodoo (SST-1) drew a single pixel per clock (and had no geometry processing) so it was not parallel at all, even inside a poly. This statement shows your level of expertise though.
> Voodoo Graphics came out in 1995, we had commercial GPUs since early 1980s.
I mean, if you think you're going to get me in a gotcha, you should know that the first thing we considered a "GPU" came out three years after the Voodoo. The GeForce 256.
But since we're talking about gaming, the first real 3D accelerator in that market was the 3dfx Voodoo, and it revolutionized gaming because even though we had graphics cards, their abilities were laughably limited (blitting was a big feature).
> so it was not parallel at all
You, uh, really should look this up. Are you consulting an LLM or something, because it's like someone who has no idea what they're talking about just randomly saying stuff. PS3! AVX-512!
"drew a single pixel" is a funny comment that kind of gives away the game. Do you have any idea what is involved in drawing "a single pixel"? This is rhetorical, because you seem to have no idea at all.
I'm just going to ignore you, but Christ you know you don't have to double down on this stuff.
His point is more about the texture filtering than about anti aliasing. Software rendered games never supported texture filtering (although they could have, at a significant cost), they always used simple nearest neighbor scaling. Of course you can turn filtering off on a GPU too, but hardly any game ever did that.
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.
Ah,Sorry,in 2001 it was actually the first, so Geforce 1 / ONE.
It hat -fasten your seatbelts- one(!) dedicated pixelshader and one dedicated vertexshader :-)
High times back then - it was like entering next dimension.
I really admire Woof[1] sourceport of DOOM and how it can achieve high fps at modern resolutions using software rendering (Sure, there are still GPU apis at work behind the scenes managing swapchain and all but rendering logic is still software). Also it's worth checking out for anybody who wants to see a good SDL3 codebase.
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.
I recently got to try out Quake 2 on 9front, a Plan 9 fork, which ran surprisingly fast on my very, very modest Thinkpad T410i with a 2.4 GHz dual core i3 at 1440x900. Plan 9 has no GPU support so all rendering is software. Even had a little lan party with other devs. I really enjoyed the software rendering, it bought back early memories of playing Q2 before we bought our Voodoo2. I even used my ploopy trackball to play. Fun times.
Presently, Plan 9 in general lacks 3D graphics but has an in-kernel 2D rendering engine referred to as devdraw. Quake 2 software rendering is done in-engine by rendering full frames to a bitmap displayed by devdraw. A fun experiment was to rcpu into my industrial DIN rail PC, a 1.2 GHz 4 core Atom, from the Thinkpad and play Quake 2. When I run Quake 2, it runs on the CPU server but graphics are sent to my laptop. However, since Q2 is rendered in-engine on the remote iPC, full frames are copied over gigE to my laptop. Q2 full screen was stuttering badly but at about 1/4 screen size it was surprisingly playable.
An other example is a port of cave story done by a 9dront dev where he integrated devdraw so the game renders by loading its assets into devdraw and issuing rendering commands. It is likely the first Plan 9 native game. It plays perfectly over an rcpu session at full screen as the rendering is done by the client side devdraw.
Another 9front dev is doing a lot of graphics work and implemented affine warping in devdraw which is useful for rapidly transforming bitmaps, e.g. scaling the output of the gameboy emulator and Doom. He and others are interested in implementing a concurrent 3D rendering software devdraw engine as we have many-core machines now. When GPU's first hit the streets, we were on single core machines. SMP machines were not affordable by mere mortals when the 3Dfx Voodoo hit the market. So the idea is, why struggle with the gargantuan task of implementing a "modern" GPU stack when you have all these CPU cores now? Why not take a step back, think about what we have learned, and extract all the performance we can from modern many-core CPUs with all sorts of vector extensions. In a Plan 9 context, you could run the game on a many core machine to handle game logic and play remotely with a bigger many-core spraying pixels at a display. Distributed gaming. Might even be able to do multiplayer with a single engine instance with multiple rendering clients attached. Fun system to play with.
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.
Shameless plug of my upcoming game [1] which uses software rendering. Also did a Show HN and write-up [2] last year for a previous game [3] using the same engine.
None of the benefits listed are exclusive to software rendering. There is literally nothing software renderer can do that GPU one can't. But I get that from historical perspective this not always was the case (esp. before programmable GPU pipelines).
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.
That screenshot is 800x600 - he probably wouldn't love software rendering at 320x240 which is what we actually had to run to get decent fps back in the day (late 90s). That was the the other big unlock of 3dfx voodoo, it could do 640x480 at 30 fps.
You know what I found this past year was that I could NOT find any way, to turn off anti-aliasing, for text inside a webview. I made a whole entire custom terminal app just for myself in Rust, Tauri, xterm.js and spent a ton of time trying to un-blur the text but failed. I redid the entire thing (well, Codex/Claude mostly) using a rust graphics library (egui) and now the text is finally sharp! and its fast. I am growing more and more anti webview with these AI coding tools.. they can almost one-shot convert a slow webview app into something that uses 1/10th the ram and 10x as fast. The text looks soooo much better, all fonts look better. In xterm.js, text looks super fat all the time (to me).
You are asking for a look that’s very niche. Not many people hate anti-aliasing so much. GNOME still has a simple UI to turn off anti-aliasing but not many apps respect that. The modern text rendering pipeline is just way too complicated from font lookup, ligatures, shaping, etc. To achieve this look in web views you’ll most certainly need to do it in <canvas>. And of course, you can still choose to draw all the text using software rendering using JavaScript or use WebGL2 and ship it to the GPU: conveniently the constructor allows you to turn off antialiasing `canvas.getContext("webgl2", {antialias: false})`.
You could also render the text inside a canvas in a web view, then you have a bit more control over the sampling. If you wanted to stick to a web view for some reason that is. Alternatively you could generate custom bitmap fonts on the fly based on the screen resolution.
Everyone is already pointing out this isn't quite software rendering but rather the rendering technique which used to be the only option. I'll add that even without a GPU, CPUs will have integrated graphics. There are CPUs that don't have this but in those cases you need a GPU. The point is that modern systems no longer use CPU to output to the screen, either there is an integrated GPU or a GPU card on the system. So in a way the term "software rendering" is only applicable to special cases of embedded systems that actually use CPUs for graphics.
I'm not totally sure what you're trying to say. Even back in the days of "software rendering" - or on those embedded systems that you're describing - you still had a piece of graphics hardware that converted the frame buffer into whatever got spit out to the monitor, so I don't think this is meaningful, really.
What's meant by software rendering is really software rasterization - the process of taking the triangles, textures, etc. of the scene and turning those into the pixels that eventually make their way to the screen. You can still do that in software on the CPU today without touching the GPU, even the integrated one. At that point you hand it off to the hardware to make its way to the screen, sure, but it's only an implementation detail that makes that different from handing 0xA0000000 over to the VGA card. The interesting part of the process, and the results, are functionally the same.
> 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.
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.
Quake II is a completely different game from Quake, isn't it? The levels, artwork and gameplay feel quite different. I personally prefer the look and feel of the original Quake, particularly when using the Arcane Dimensions mod.
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.
It's like 2.5D, maybe like 2.75D or so. Technically, every map in vanilla Doom is a 2D map, with various "sectors" in the map having height; they're rendered in a sort of pseudo 3D, but crucially the map will never have one floor about another¹. I don't think I'd argue the 2D maps technically make it "not 3D", though.
However, Doom also renders textures using an algorithm that sort of paints walls as like vertical lines of sorts. The exact algorithm it uses makes it hard to look up (to pitch), and I think impossible to roll the camera. See <https://en.wikipedia.org/wiki/Doom_engine#Rendering> — it has a good animated graphic of what happens if you do look up, and the differences between the output of Doom's software renderer's algorithm and something actually rendering 3D.
¹modern ports have ways to accomplish this, and even before there were direct ways of doing it, clever map layout and instantaneous teleporting can get pretty close.
Raycasting (in gaming, some graphics folks just use it as another term for raytracing) means to fire a ray for each column of the screen, identify where it collides with a wall, and use that to determine what to render for that column - it's basically per-column raytracing.
DOOM's engine instead uses a BSP tree so that, from any position, you can determine which walls are on-screen instantly just by walking the tree - the nearer walls appear earlier in the traversal than farther walls. It's still column-based (it tracks whether each column has been drawn and won't draw further walls behind an already drawn column, and stops drawing once all columns are filled), but there's no rays cast.
A few years ago I seriously contemplated making a game using software rendering, in part because the only target was SDL. I actually got a 3D engine running 2K@60Hz with HL2-level scenes, with the CPU basically idle, so it's not a terrible idea.
(Then LLMs started taking off and I decided I needed to reskill out of the industry, just in case)
I know this is not entirely what this article is about, but I love software rendering for desktop apps. It seems to me that the performance impact with proper paint invalidation is negligible, but doesn't suffer from the same driver issues as hardware accelerated rendering seems to have. Bonus that it doesnt use any GPU resources in the age of AI
Michael Abrash's Graphics Programming Black Book is still one of my all time favourite. What they did back then was almost black magic. I learned a good part of maths, cs and physics trying to mod id1 with this book during my teenaghood.
Unfortunately I didn’t do anything as impressive as modding a game; I read the book because the writing style itself was engaging and gripping like a novel.
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.
It's a faithful port of Quake's original software renderer. Everything happens on the CPU, which made it easier to match the original exactly. In theory the same could be done on a GPU, but I think it would be harder and messier.
The trade-off with software renderer is that it's more code. With GLQuake much of the actual rendering work is handed off to OpenGL itself, i.e. the driver and the GPU. In the software renderer, the engine does all of that in its own code.
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?
Even the oldest and cheapest CRT monitor my family had was pretty pixel-accurate unless you were right at the edges. I was doing pixel art on it as a child and had no issues at all.
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.
Its so interesting to me that back then we would have died for the graphics we have today, and now this retro look is being appreciated. I mean, it definitely has an aesthetic but its generally unappealing. I guess nothing is immune to nostalgia and pining for being at the age when we had less responsibilities and life seemed easier.
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 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.
Yeah, it may not be in the spirit of 90s software rasterizing, but since you don't offload the transform, lighting, and rasterizing procedures to specialized hardware, you technically do it "with code". The parallelization goes against the spirit though.
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.
Ah the software rendering era. Where I gained 10fps by adding a sound card.
I'm interested in hearing more
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.
SOUNDBLASTER 2.0 !!!!!!
A 16(!!!) bit ISA slot card, which revolutionized PC-audio-experience.
Are they still on the market or crashed by the ever-more-increasing onboard chips?
And there was Gravis Ultrasound, where you could upload samples into the RAM of the soundboard (that was like superpowermegatech back at these days :-) IIRC, the highest degree of fidelity was fu**ng 16 MB of onboard RAM on the soundboard.
:-D
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
So was Waterluvian, I assume, which is probably why they added the card!
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).
Something that always seems to surprise me when I remember it today: Playing an MP3 on my Pentium CPU in 1996 worked, but it _really_ brought the system to its knees. I could choose between listening to MP3 music or interacting with some other program (mIRC, Netscape, etc) but certainly not both.
That probably had more to do with decompression than sound mixing though, right?
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.
CPUs from that era were single core and pretty slow. They had to do everything like game logic, graphics, sound, etc all at once, so it was often resource starved. Sound took some resources, sometimes significant depending on the sound and what else the cpu was doing, unless it was a really simple sound (think NES style sound). Moving that to a dedicated sound card meant the cpu didn't have to worry about sound anymore.
Sound, like a lot of things, could be seen as a peripheral and a lot of peripherals back then needed their own cpu to perform well. One interesting fact I recently learned is the commodore 64 was so resource starved, the external floppy drive you could buy had its own 6502, just like the C64 did as its main processor. It just had to off-load that to another cpu because its own cpu was too busy to reliably run a disk drive. There are other reasons for this like commodore's experience in drives previously was this kind of architecture so they went with what they knew, but its a bit interesting to know your floppy drive was essentially another C64 with its own commodore OS and ram and 6502.
This should really be titled "I love pixelated textures".
> "3D cards smoothed textures with bilinear filtering"
You can just not do that.
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.
Why is it “impossible”? If you mean that a rendered frame has to reside in the graphics memory before being sent to the display, then I think that was the case even when software rendering was a thing.
If you mean rendering a frame entirely in the main memory by the CPU, then there is nothing making it impossible. I mean, most major 3D rendering software still have CPU renderers as an option. Slow, but doable.
P.S: I am using offline renderers here as an extreme example. A game renderer - especially for scenes like Quake’s - are definitely going to be far simpler and cheaper.
By 'impossible', I mean it in a very strict sense of blitting full-screen frames directly into the framebuffers provided by HDMI or (e)DP representing a visible surface. This is still kind of possible in Windows when games are properly full screen and not 'borderless full screen', but the OS still does compositing in the background, and the GPU is still involved to some extent.
Of course, offline rendering is a different story.
I suppose the disagreement here is on the scope of “rendering.”
Using the extra unpopulated memory slots on your VGA card to get that 1024x786 at 256 colors. 800x600 is the largest which will fit in 512k of video memory at that colors depth, or getting 16bit color space in 800x600 due to having doubled your memory from 512k to 1024k. And those were definately the software rendering days, every ramdac needs it's own memory pool.
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.
Indeed. I wrote up a commment[1] explaining why code editors needed graphics acceleration some months ago; this ties in to that.
[1]: https://news.ycombinator.com/item?id=44966266
It's just like how pixelated 2D graphics is called "8-bit" now.
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.
Valve added this as an option to Half-Life in the 25th anniversary update, and I thank them for it - it looks much cooler.
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.
Considering how many things are broken when you play in d3d or OpenGL mode I’m not so sure. :P
That said, Black Mesa is a marvelous piece of work. The Xen levels feel like they finally finished them.
makes me wonder how would gameplay fare when a gpu renders the game with very limited options. Sometimes higher FPS would play weirdly with the physics engine and some moves you could do when capped at 24fps were not possible at 60fps.
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.
If you want to have the true PSX gaming experience you can also round all vertex coordinates to the next pixel and force noperspective interpolation.
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.
His definition of software rendering is
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.
He says he likes the look, that's subjective and doesn't need arguments. You wanted to read another, technical article.
He likes the look of nearest neighbor texture sampling, not software rendering.
You can do nearest neighbor in hardware rendering and you can do bilinear in software rendering. Rendering mode and texture sampling are two totally different things.
I think there's more to it. In Quake, the software renderer decides the color of each pixel, based on running some code on the CPU, which can do anything. GPU rasterization is far more standardized, with standards defining how each triangle ought to be sampled at each pixel coordinate (and the fact that you're sampling triangles in the first place).
The whole process is standardized with GPU rendering, leading to ways of rendering and content authoring that's quite different from how things used to be, and while definitely possible, modern 'retro' games often render like GPU accelerated games and just disable texture filtering, which doesn't quite give you the look.
He mentions Build games, which are not strictly polygonal.
While general purpose computation exists on GPUs, and the standard rasterization pipeline can be implemented in software, graphics cards have pushed people towards a 'look and feel' which comes partly from standardized data structures, content authoring and rendering approaches, that have made games feel samey.
Whereas with software rendering, essentially you have an array of pixels which you can set to a certain color, and the rest is up to you, which made devs come up with unique ways of rendering and authoring content.
The intricate level designs that were made possible with BSP based tools and are basically 'free' to render in software, had hell of a time making the transition to GPUs, as they rely on traversing the tree while drawing pixels, whereas for the GPU, you need to submit a list of triangles (unless you go GPGPU)
Modern games look samey because they all want the same result - photorealism - and aren't fussy about using an off-the-shelf solution - i.e. UE5 and Unity. We have absolutely insane levels of control over the rendering pipeline and almost everything is programmable; the GPU is an endless fountain of parallel programming. But in order to take advantage of any of that you have to actually start changing engine code, or write your own renderer, and games don't care because the default UE5 look is "good enough".
There is some standardization in that, if you issue geometry and sample textures normally, you will be relying on hardware units for rasterization and texture sampling, and those do have a relatively limited set of options for how they work. However, those options encompass most if not all of what 3D engines could ever want or need, even the early 3D ones that had all sorts of hacks. The kinds of things GPUs can't actually rasterize in hardware are things like NURBS or metaballs, but this doesn't matter because the industry settled on triangles[0] as the medium of real-time 3D really early on.
A lot of the look of old 3D games comes down to them doing things the lazy way, and I'm proud to say the lazy way is still very much supported - so long as you turn off features that didn't exist later on and limit yourself. I'm not as familiar with old DOS games, so I'll use the PS1 as an example. The "PS1 look" is very much a result of its incredibly limited rasterizer, whose limitations can be trivially emulated in modern hardware:
1. Don't allocate or bind a depth buffer. You will need to Z-sort your geometry every frame. Part of the "PS1 look" is that some games did it wrong; if you do it correctly you'll be burning performance for no visual benefit. Pick a scheme that breaks in a visually interesting way. Likewise make sure to not allocate any multisampling since the PS1 didn't anti-alias either.
2. Restrict the precision of vertices in your vertex shader by rounding them. The PS1 did vertex math with incredibly low precision and it makes vertices wobble.
3. Restrict the precision of UVs in your fragment shader. PS1 UVs were 0-255, so you want 1/256 precision.
4. Aggressively discard geometry that clips the edge of the viewport. The PS1 did not have proper polygon clipping; you just couldn't render off the end of the viewport, so games had to discard geometry and subdivide polygons to avoid things disappearing. This is another "if you do it well, nobody will notice" thing.
5. Turn off perspective-correct attribute interpolation; this will make your UVs warp and distort at certain angles. You do this with the `noperspective` attribute in GLSL.
6. Disable bilinear filtering when sampling textures.
7. Allocate and render to a low-precision color buffer. Lots of games would change the color depth to match the available VRAM. This is probably the hardest aspect to emulate unless you are actively counting VRAM usage and sticking to realistic values.
8. Bitcrush your textures before uploading them. The same reasoning applies here. Also, don't upload any mipmaps.
9. Lighting was done through vertex colors, which were calculated on the CPU. You don't have to limit yourself to CPU lighting but you do have to make sure lighting is done in the vertex shader.
10. Optional: implement the early model PS1 texture banding bug in your fragment shader.
This will give you a rendering pipeline that is good for basically all purposes except bit-accurate PS1 emulation. Of course, if you were doing bit-accurate emulation, nothing stops you from issuing a screen-filling quad and writing a GPU shader that does software rasterization on the GPU. Or launching a compute shader that accesses the framebuffer arbitrarily - although you do have to worry about memory coherency across warps and workgroups. Texture sampling can also be done "in software" if you so wish - i.e. by doing unfiltered reads to the texture which are glorified array lookups, and then filtering those reads as you wish.
[0] There was a brief moment where quads might have been able to win - artists like to work with them, and Nvidia was shipping quad hardware. But the advantage died very quickly, and quads can be easily converted to triangles - not so much the other way around.
Technically you're right, a gpu is just a bunch of ALU and FPU in a way, we just defer computation to a massive array of them so the cpu can do other things, what you do on these gpu cores is up to you.
That said, historically, software rendering meant non-accelerated passes that could be carried out by a cpu at decent enough FPS.
ps: some could also say that a FPU is not software rendering since early x86 didn't have it in the cpu.
The author likes the look of the tradeoff made due to the limitations CPU power imposed on the rendering model for real time 3D games 30 years ago.
Yeah you can hack configurations or create your own game to mimic this look.
If you read the post you will see it’s not only about the texture sampling, but also the color depth.
OP picked a good headline. You are fighting for semantics nobody cares about, and picking a more complicated synecdoche.
But if you want to experience GLQuake that looks like software-rendered Quake, that's a simple settings change in your GPU driver, overriding the texture sampling mode. That's literally the only difference. I'm not sure the author is aware that it is a viable option to tweak the hardware rendering this way.
> if you want to experience GLQuake that looks like software-rendered Quake, that's a simple settings change in your GPU driver, overriding the texture sampling mode. That's literally the only difference.
Is that the case?
https://fabiensanglard.net/3dfx_sst1/ has a side-by-side screenshot comparison of the two, and software Quake's colours and lighting look way more rich and vibrant; it's not just smoother textures. It's possible that GLQuake/one of the many source ports since has improved on this though.
Of course I know this is a particular quality of GLQuake and not an actual limitation of hardware rendering. And I agree with in general with the contention that this article is talking about a particular art style associated with mid 90s software rasterizers rather than about "software rendering" itself.
In the caption under the image it explains that the 3Dfx card lacked gamma correction, which is why it looked so saturated. The Voodoo was a pass-through card: it had its own DAC for generating display signal when a full screen 3D game was running, but otherwise your 2D accelerator was used. So on the same machine a software rendered game and a 3D accelerated game had different output even if the frame buffer was identical, due to different circuitry (and the Voodoo card’s circuitry lacking gamma correction made it hella saturated as you see here).
This could have been corrected on the art side, by recalibrating the texture maps to the voodoo gamma levels, and that’s why there are great arcade machines from that era with wonderful graphics (designed for the hardware they were running in production), but GLQuake looks all washed out.
It's not just the gamma correction. Things like water are different in GLQuake.
DF Retro has good comparison of software Quake, GLQuake and VQuake (for the Rendition Verite).
https://www.youtube.com/watch?v=0KxRXZhQuY8
Are you sure? I haven't played enough Quake to know either way, but I did play Deus Ex in software mode (unreal engine), and that had a lot of differences to the other renderers. I very much doubt texture sampling mode alone would reach a similar result.
(It even had graphic errors, green textures in the faces etc giving everything a very alien look. But that's not what I mean).
It's not correct. A notable example is the water effects.
It depends on particular renderer, obviously. Not all software renderers were being given appropriate care.
May be a couple settings. IIRC full bright textures didn't translate well in early GPU renderers. Often they'd appear shaded as if they weren't light sources at all.
I agree with you and I think others aren't understanding your point. "Hardware rendering" can also be achieved by the CPU in "software". It will just not be realtime. Just fire up Blender and render scenes using the CPU, which is a standard option. You will see how amazing "software" rendering can be.
There's nothing special about the GPU besides doing certain kind of operations that are very useful for graphics (and AI, among other things) really efficiently. The distinction should never have been "software rendering" vs "hardware rendering", but "what CPU rendering could achieve when GPUs weren't widespread" versus "what GPU rendering has been able to achieve since they became available".
I like CPU rendering for the mere fact that it doesn't involve special GPU hardware. More of a challenge, more of a throwback to 80s/early 90s gaming.
This is fine, but then we'd also have to specify your CPU performance constraints. If you max out a modern CPU for CPU rendering, you will get graphics vastly exceeding what 80s/90s CPU rendering could achieve.
> the examples given to highlight the supposed positives of software rendering can all be achieved on GPUs.
Any look in older games, 2d or 3d, can be achieved on modern GPUs, so that seems like a vacuous thing to state.
Not necessarily. Someone unfamiliar with graphics might believe that there’s something about a CPU that a graphics card doesn’t have such that the look can’t be achieved. Certainly the author of this piece seems to believe that.
> Certainly the author of this piece seems to believe that.
That's unfair, especially if you read his other articles.
> Someone unfamiliar with graphics
... is probably not the intended audience of a hobbyist, specialized blog such as the one we're discussing.
What they meant was: "This aesthetic isn't exclusive to software rendering". I thought the rest of their comment made that pretty clear once you got past the first sentence.
I think the issue is that modern aliasing can be done without a GPU, so it's not that he loves software rendering, it's that he loves the style the constraints of the time imposed, and that style is not married to CPU-exclusive rendering.
Yes - but most of the rest of the article describes something different! (Which is what the post you're replying to explains)
yup, it should be renamed to "I Love GL_NEAREST_MIPMAP_NEAREST"
Real players know you us the coarsest mipmap level the whole time, so every texture is something like 4 pixels. And 320x200 and directmouse. It's the smooth movement, high fps and direct control that provides the sense of "being there". Not the graphical fidelity.
I think you've almost exactly described my Counter-Strike setup 25 years ago.
Friends at LAN parties complained how ugly it was and my rebuttal was usually: "I'm afraid it stays unless you can buy me a better video card." The fact that the CRT slowly drifted to a yellow tinge on everything didn't help the asethetics--especially on de_dust. The GPU at the time might have been a Riva 128 ZX.
Is there a video somewhere (or easy download/install on linux) so I can see/play what this looks like
Shameless plug for my own project, Quake-SRP (the Slop Rust Port).
Video: https://www.youtube.com/watch?v=8TvVMzyxACc
Browser(shareware): https://quake-srp.pages.dev/
Source: https://github.com/terrapapagalli1516/quake-srp
This is a good example of human-agent teaming tbh. Nice one.
I love the graphics in your video, really interesting and fit the vibe of the original game too.
Extraordinary attention to detail. Looks beautiful!
Of course you can but I think author’s point is to actually test/evaluate maximum performance of true software rendering on modern machines, and this is fine and refreshing exercise, even with filtering.
This actually what I have also returned to in my latest demoscene demo: https://www.pouet.net/prod.php?which=106969
It’s 100% software rendering on CPU just multithreaded. But no metal/direct3d just framebuffer and rest is yours routines… and I actually added bilinear filtering…
Still fun project to do and remind yourself about fundamental algorithms behind elementary 3D graphics
You have to admit, it makes for a less catchy title
T-shirt worthy
Yeah, when glquake and the Voodoo1 came out, I was actually initially disappointed because I'd seen demos of vquake on the verite and its texture mapping was closer to the original. But you couldn't complain about the framerate of the 3dfx.
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?
Here’s an analogy. Suppose someone said, “I love manual transmission cars” and then described in detail the physical knobs and dials that all the cars from the 1950s had.
It turns out what they like is physical knobs and dials. You can have those in automatic transmission cars. It so happens that most modern automatics also have shitty touchscreens.
(I know this analogy isn’t precise because there was a long period of automatics with physical controls, but bear with me.)
The point is that there’s nothing _inherent_ to software rendering that’s responsible for the thing he likes. The distinction is useful because, for example, he could go seek out modern games with the look he likes. Or make games. And if he thought the thing he likes comes from having a software renderer, he’d leave a lot of performance and power efficiency on the table for no good reason. He likes a certain rendering style that’s equally achievable with both GPU and CPU rendering. The choice of hardware should probably be driven by considerations like performance, debuggability, platform support, availability of libraries, etc.
Ah, I see. Maybe: somebody says they love audio cassette players, and start talking about the super tactile mechanical buttons and switches that go chunk in a satisfying way. You could rightly object that that you can put buttons like that on an mp3 player. But it's a historical fact that these things are actually linked, in a way that's meaningful to people, namely in their personal nostalgic experiences.
The point is that the thing that OP likes has nothing to do with whether something is rendered in software or hardware.
"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.
This is incorrect. It is exactly the same algorithm as circuits in the GPU or as instructions on the CPU. No difference, except one: the way data is pipelined on the GPU makes texture blending free, or nearly so. So to show off, every 3D game back then turned it on (an OpenGL/Glide/D3D configuration option) and everything got smoothed out, often with no option to turn it off. That's why it ends up looking different: because the game itself selected different interpolation in accelerated vs software rendered. It was a game choice.
These days you can use different presets to override those choices, and have your 8K, 240Hz Quake look software rasterized, if you want.
> This is incorrect
Incorrect how? It's correct in that software renderers of the time TFA describes mostly looked like this, and GPU renderers didn't (of course, they weren't called GPUs back then), and there's a reason for this. Even you admit it later in your comment.
So saying "it has nothing to do" with software renderers (of the time) is wrong. It has something to do with how software renderers vs GPUs were used during that era in practice. It's also true you can simulate one with the other, but that doesn't make it incorrect or unrelated.
> So to show off, every 3D game back then turned it on (an OpenGL/Glide/D3D configuration option) and everything got smoothed out, often with no option to turn it off. That's why it ends up looking different
So it had something to do after all! So TFA has a point. He means software renderers in the sense you're describing here, and it's clear from the text. He's not implying you cannot use a GPU to achieve the same result.
Software renderers can do bilinear filtering. It does not change any aspect of how the software renderer works. I’ve implemented this, so I know: it’s a couple of lines change in the texture lookup. But it adds three lerps per channel, per pixel, whereas nearest neighbor requires none. That’s 9 multiply-adds in the tightest inner loop that would normally have zero. In the 3D accelerators of the era, the pipelines were all fixed-function (programmability is why NVIDIA renamed it GPU when they released the GeForce 256), so those lerps were in the silicon whether you used them or not. Bilinear filtering had zero impact on render speed, so long as you weren’t saturating video RAM with the added texture lookups.
TL;DR a software rendered game and a 3D accelerated game from that era looked VERY different, but that difference was largely down to a feature that was often implemented in the software renderer, and was only a couple of lines in the innermost loop. But rarely used outside of a few choice effects due to the massive performance impacts. On 3D accelerators it was free, and default-on.
(I’m an old fart that cut my teeth in programming writing software renderers with the community at Flipcode, if anyone remembers that.)
I'm not disputing the technical details of anything you're saying. I don't think the author of TFA is, either.
So when you say "this is incorrect", and also:
> Software renderers can do bilinear filtering.
What do you mean? Nobody is disputing they can. The author is talking, in my opinion, about how software and hardware renderers of that time behaved in practice in games you could buy at the time. It's just that peppering the text with "at the time", "typical" and "in practice" makes for very cumbersome reading.
I'm also an old fart, by the way :) I don't remember Flipcode, but I wrote software renderers for fun and also for my CS coursework. I read my Abrash and my Foley & van Dam, etc. I then lost track of that, time was finite and I had to choose my hobbies more carefully!
This is ridiculous. He explained it perfectly and he was right stating that it has "nothing to do with software rendering". The fact that people specifically chose to do it differently on hardware makes nothing about what the article mentions specific to software rendering. Otherwise if you do the smoothing on the CPU you have to call it a hardware renderer now to be consistent.
It's not ridiculous. It's also perfectly clear from TFA, one has to go out of their way to misinterpret this.
E.g.
> Software renderers generally sample textures pixel by pixel, so every texel stays a crisp square. Early 3D cards smoothed textures with bilinear filtering, which looked impressive in 1997 but turns everything soft and blurry to my eye now.
The author is a hobbyist discussing things in context. Early 3D cards, bilinear filtering as done in '97, etc. You cannot take random words and criticize the article. This seems to be a retrogaming hobbyist blog about doing stuff with old hardware and games.
Nitpicking is pointless.
The point is that the look is not inherent to software rendering. You're misinterpreting this as some kind of denial of historical association. You're own quote there identifies texture filtering as the difference. Explaining that you can get those sharp textures with hardware acceleration, isn’t “pointless nitpicking.”
I think the comments section is the perfect place to nitpick something like this.
"Software" isn't the point. You can do the exact same math on CPU or GPU. OpenGL supports nearest neighbor texture filtering on whatever hardware you run it on since 1992, one year before Doom even came out.
But in practice, this didn't happen, which is what TFA seems to be all about. So it's not incorrect to talk about software renderers (of the time) vs hardware accelerated graphics (of the time) and how they were used in practice (at the time). It's just cumbersome to write "at the time", and it's understood from context; at least I did. It also helps to look at the rest of the blog's articles and what the blog is about...
Sure, software rendering mostly used nearest neighbor, but it's not crisp because it's software rendering, which is what the article claims.
I isn't "simulated" by GPUs, it is a rendering mode that GPUs had since before they were called GPUs.
The reason software rendering look different from 3D accelerated games (incl. 3Dfx) is nearest neighbor filtering and low resolution, which were necessary to keep a reasonable framerate. At the time, it was considered ugly, so if your hardware supported bilinear filtering for free, it was turned on, but it didn't have to.
In the time of fixed pipelines (3Dfx to GeForce 3), you couldn't do arbitrary operations on pixels, so some effects, like the kind that are common in the demoscene were software only. So games that used these effects, like Comanche voxels can indeed be thought as representative of software rendering, and they can, of course, be simulated on modern GPUs as everything that was done on software before can.
But the article uses Quake as an example. I may be wrong, but I don't think it does anything that can't be done by a fixed pipeline GPU. In fact, even keeping the same style (nearest neighbor filtering + low resolution), hardware rendering will probably look better because the GPU does proper perspective correction on every pixel. The tricks used by the Quake engine are awesome, but they don't beat raw power.
> I isn't "simulated" by GPUs, it is a rendering mode that GPUs had since before they were called GPUs.
Yes, of course. That's what I meant. I didn't mean "simulate" as in fake, I meant it more as in "replicate the same effect". Ultimately, hardware and software are equivalent, give or take matters of costs, debugging and performance.
> In the time of fixed pipelines (3Dfx to GeForce 3), you couldn't do arbitrary operations on pixels, so some effects, like the kind that are common in the demoscene were software only. So games that used these effects, like Comanche voxels can indeed be thought as representative of software rendering, and they can, of course, be simulated on modern GPUs as everything that was done on software before can.
Yes, I think that's the spirit in which TFA's term "software rendering" must be taken. The context is old games and their pipelines as they were used at the time, not more recent GPUs or practices.
> The tricks used by the Quake engine are awesome, but they don't beat raw power.
I really don't think the article is contesting this.
They mean that what the OP prefers about it is not the fact that it’s done in software. “This” is “the thing the OP seems to prefer”.
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 introduce aliasing on fast moving element which is far more annoying than blurring
The alias was there from the start. It just couldn't find where it was in an older frame to do the anti aliasing.
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.
Software rendering went out of style because z-buffer based rasterization is embarrassingly parallel and benefits from a hardware implementation.
> it's called turning off spatial anti-aliasing.
It's called "nearest neighbour texture sampling", as opposed to bilinear/trilinear/anisotropic
"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 its performance in rendering textured z-buffered triangles. 3D graphics can really go wide only on wireframe/points, z-buffer forces sequencing between polys so the parallelism there is very limited.
Parallel processing was fully in force in the very first GPUs, like the Voodoo. Not like a modern GPU with thousands of more flexible shader cores, but the first iteration had a pipeline architecture that saw multiple blocks operating on rendering separate parts of the pipeline in parallel. This was revolutionary. Especially given that CPUs at the time had a single core.
I'm not sure what the PS3 comparison is for, or why we're comparing a 2026 AVX-512 CPU with a 2006 gaming console. Okay? A modern GPU can obliterate any CPU in SIMD, presuming you conform with the types it wants. Add that it's weird to bring up as AVX and other SIMD techniques are basically the same sort of architecture, parallelizing a problem.
> 3D graphics can really go wide only on wireframe/points, z-buffer forces sequencing between polys so the parallelism there is very limited.
Rendering a 3D is scene is the very definition of embarrassingly parallel. While optimizers can cull the scene, you know that the entire depth within the frustum (there are a variety of optimizing techniques to minimize the overdraw, but it's a part of rendering a scene) is "rendered" and in amalgamation the Z-buffer values are compared and discarded, blended, or whatever? It is an extraordinarily parallel operation.
> the very first GPUs, like the Voodoo
Voodoo Graphics came out in 1995, we had commercial GPUs since early 1980s. Also it's funny that you believe it was "full force" parallel because specifically Voodoo (SST-1) drew a single pixel per clock (and had no geometry processing) so it was not parallel at all, even inside a poly. This statement shows your level of expertise though.
How bizarrely hostile. So weird.
> Voodoo Graphics came out in 1995, we had commercial GPUs since early 1980s.
I mean, if you think you're going to get me in a gotcha, you should know that the first thing we considered a "GPU" came out three years after the Voodoo. The GeForce 256.
But since we're talking about gaming, the first real 3D accelerator in that market was the 3dfx Voodoo, and it revolutionized gaming because even though we had graphics cards, their abilities were laughably limited (blitting was a big feature).
> so it was not parallel at all
You, uh, really should look this up. Are you consulting an LLM or something, because it's like someone who has no idea what they're talking about just randomly saying stuff. PS3! AVX-512!
"drew a single pixel" is a funny comment that kind of gives away the game. Do you have any idea what is involved in drawing "a single pixel"? This is rhetorical, because you seem to have no idea at all.
I'm just going to ignore you, but Christ you know you don't have to double down on this stuff.
His point is more about the texture filtering than about anti aliasing. Software rendered games never supported texture filtering (although they could have, at a significant cost), they always used simple nearest neighbor scaling. Of course you can turn filtering off on a GPU too, but hardly any game ever did that.
spatial anti-aliasing
aka (just) anti-aliasing, we are talking original quake 1 era, after all.
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.
Ah,Sorry,in 2001 it was actually the first, so Geforce 1 / ONE.
It hat -fasten your seatbelts- one(!) dedicated pixelshader and one dedicated vertexshader :-) High times back then - it was like entering next dimension.
(Two chips, guys, two!)
And alternative rendering methods like Commanche's voxel weren't doable on the GPU for a long time.
....and it always sucked, sucks currently and will suck in the future. For several reasons.
The market clearly decided the tech. And yes, for I felt Comanche'94 was just uggly and "bricky"
I really admire Woof[1] sourceport of DOOM and how it can achieve high fps at modern resolutions using software rendering (Sure, there are still GPU apis at work behind the scenes managing swapchain and all but rendering logic is still software). Also it's worth checking out for anybody who wants to see a good SDL3 codebase.
[1] https://github.com/fabiangreffrath/woof/
[2] https://github.com/fabiangreffrath/crispy-doom/ (simpler doom port from which woof inherited its rendering code)
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.
Unless you were playing on a TV CRT, I don't think so. PC monitors of the time were pretty sharp already.
I recently got to try out Quake 2 on 9front, a Plan 9 fork, which ran surprisingly fast on my very, very modest Thinkpad T410i with a 2.4 GHz dual core i3 at 1440x900. Plan 9 has no GPU support so all rendering is software. Even had a little lan party with other devs. I really enjoyed the software rendering, it bought back early memories of playing Q2 before we bought our Voodoo2. I even used my ploopy trackball to play. Fun times.
Presently, Plan 9 in general lacks 3D graphics but has an in-kernel 2D rendering engine referred to as devdraw. Quake 2 software rendering is done in-engine by rendering full frames to a bitmap displayed by devdraw. A fun experiment was to rcpu into my industrial DIN rail PC, a 1.2 GHz 4 core Atom, from the Thinkpad and play Quake 2. When I run Quake 2, it runs on the CPU server but graphics are sent to my laptop. However, since Q2 is rendered in-engine on the remote iPC, full frames are copied over gigE to my laptop. Q2 full screen was stuttering badly but at about 1/4 screen size it was surprisingly playable.
An other example is a port of cave story done by a 9dront dev where he integrated devdraw so the game renders by loading its assets into devdraw and issuing rendering commands. It is likely the first Plan 9 native game. It plays perfectly over an rcpu session at full screen as the rendering is done by the client side devdraw.
Another 9front dev is doing a lot of graphics work and implemented affine warping in devdraw which is useful for rapidly transforming bitmaps, e.g. scaling the output of the gameboy emulator and Doom. He and others are interested in implementing a concurrent 3D rendering software devdraw engine as we have many-core machines now. When GPU's first hit the streets, we were on single core machines. SMP machines were not affordable by mere mortals when the 3Dfx Voodoo hit the market. So the idea is, why struggle with the gargantuan task of implementing a "modern" GPU stack when you have all these CPU cores now? Why not take a step back, think about what we have learned, and extract all the performance we can from modern many-core CPUs with all sorts of vector extensions. In a Plan 9 context, you could run the game on a many core machine to handle game logic and play remotely with a bigger many-core spraying pixels at a display. Distributed gaming. Might even be able to do multiplayer with a single engine instance with multiple rendering clients attached. Fun system to play with.
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.
Shameless plug of my upcoming game [1] which uses software rendering. Also did a Show HN and write-up [2] last year for a previous game [3] using the same engine.
[1] https://store.steampowered.com/app/5277420/Omega_Transmissio... [2] https://news.ycombinator.com/item?id=45270981 [3] https://totenarctanz.itch.io/a-scavenging-trip
None of the benefits listed are exclusive to software rendering. There is literally nothing software renderer can do that GPU one can't. But I get that from historical perspective this not always was the case (esp. before programmable GPU pipelines).
The thing is, back then CPU were super slow and more complex software renderers were actually not useable/available
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.
Sources: * https://framebuffer.io/project/quake * https://browser.geekbench.com/geekbench2/327940 * https://browser.geekbench.com/geekbench2/529270
IIRC,didnt had Doom et al some caps with the FPS?
Didnt someone have software rendering for Crysis on a third-generation Threadripper?
That screenshot is 800x600 - he probably wouldn't love software rendering at 320x240 which is what we actually had to run to get decent fps back in the day (late 90s). That was the the other big unlock of 3dfx voodoo, it could do 640x480 at 30 fps.
You know what I found this past year was that I could NOT find any way, to turn off anti-aliasing, for text inside a webview. I made a whole entire custom terminal app just for myself in Rust, Tauri, xterm.js and spent a ton of time trying to un-blur the text but failed. I redid the entire thing (well, Codex/Claude mostly) using a rust graphics library (egui) and now the text is finally sharp! and its fast. I am growing more and more anti webview with these AI coding tools.. they can almost one-shot convert a slow webview app into something that uses 1/10th the ram and 10x as fast. The text looks soooo much better, all fonts look better. In xterm.js, text looks super fat all the time (to me).
You are asking for a look that’s very niche. Not many people hate anti-aliasing so much. GNOME still has a simple UI to turn off anti-aliasing but not many apps respect that. The modern text rendering pipeline is just way too complicated from font lookup, ligatures, shaping, etc. To achieve this look in web views you’ll most certainly need to do it in <canvas>. And of course, you can still choose to draw all the text using software rendering using JavaScript or use WebGL2 and ship it to the GPU: conveniently the constructor allows you to turn off antialiasing `canvas.getContext("webgl2", {antialias: false})`.
You could also render the text inside a canvas in a web view, then you have a bit more control over the sampling. If you wanted to stick to a web view for some reason that is. Alternatively you could generate custom bitmap fonts on the fly based on the screen resolution.
Everyone is already pointing out this isn't quite software rendering but rather the rendering technique which used to be the only option. I'll add that even without a GPU, CPUs will have integrated graphics. There are CPUs that don't have this but in those cases you need a GPU. The point is that modern systems no longer use CPU to output to the screen, either there is an integrated GPU or a GPU card on the system. So in a way the term "software rendering" is only applicable to special cases of embedded systems that actually use CPUs for graphics.
I'm not totally sure what you're trying to say. Even back in the days of "software rendering" - or on those embedded systems that you're describing - you still had a piece of graphics hardware that converted the frame buffer into whatever got spit out to the monitor, so I don't think this is meaningful, really.
What's meant by software rendering is really software rasterization - the process of taking the triangles, textures, etc. of the scene and turning those into the pixels that eventually make their way to the screen. You can still do that in software on the CPU today without touching the GPU, even the integrated one. At that point you hand it off to the hardware to make its way to the screen, sure, but it's only an implementation detail that makes that different from handing 0xA0000000 over to the VGA card. The interesting part of the process, and the results, are functionally the same.
I too. So that I have written many software renderers in many years. A video with my recent project having a software renderer: https://www.youtube.com/watch?v=NepOPAPDvwA
> 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.
And for those who want more of this type of game I must absolutely recommend the game “Supplice” as well.
My understanding was they removed that software renderer specifically because it didn't run well.
It's still there, though I don't play with it. The characteristic Build mouse look distortion makes me queesy.
> Games worth trying
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.
Quake II is a completely different game from Quake, isn't it? The levels, artwork and gameplay feel quite different. I personally prefer the look and feel of the original Quake, particularly when using the Arcane Dimensions mod.
> Quake II (a slight improvement over Quake)
That colored lighting, though.
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.
Is software rendering the reason that people can run doom on everything?
Yes
Yes, although Doom isn't categorized as a real 3D engine as such.
What is Doom if it isn’t a real 3D engine? Is it faking it somehow?
It's like 2.5D, maybe like 2.75D or so. Technically, every map in vanilla Doom is a 2D map, with various "sectors" in the map having height; they're rendered in a sort of pseudo 3D, but crucially the map will never have one floor about another¹. I don't think I'd argue the 2D maps technically make it "not 3D", though.
However, Doom also renders textures using an algorithm that sort of paints walls as like vertical lines of sorts. The exact algorithm it uses makes it hard to look up (to pitch), and I think impossible to roll the camera. See <https://en.wikipedia.org/wiki/Doom_engine#Rendering> — it has a good animated graphic of what happens if you do look up, and the differences between the output of Doom's software renderer's algorithm and something actually rendering 3D.
¹modern ports have ways to accomplish this, and even before there were direct ways of doing it, clever map layout and instantaneous teleporting can get pretty close.
It's considered 2.5D: https://web.archive.org/web/20030616094237/https://www.phoen...
Modern Doom games are real 3D, but the original was using an advanced form of raycasting[0].
[0]https://doomwiki.org/wiki/Doom_rendering_engine
No it doesn't; that's a common misconception.
Raycasting (in gaming, some graphics folks just use it as another term for raytracing) means to fire a ray for each column of the screen, identify where it collides with a wall, and use that to determine what to render for that column - it's basically per-column raytracing.
DOOM's engine instead uses a BSP tree so that, from any position, you can determine which walls are on-screen instantly just by walking the tree - the nearer walls appear earlier in the traversal than farther walls. It's still column-based (it tracks whether each column has been drawn and won't draw further walls behind an already drawn column, and stops drawing once all columns are filled), but there's no rays cast.
A few years ago I seriously contemplated making a game using software rendering, in part because the only target was SDL. I actually got a 3D engine running 2K@60Hz with HL2-level scenes, with the CPU basically idle, so it's not a terrible idea.
(Then LLMs started taking off and I decided I needed to reskill out of the industry, just in case)
I know this is not entirely what this article is about, but I love software rendering for desktop apps. It seems to me that the performance impact with proper paint invalidation is negligible, but doesn't suffer from the same driver issues as hardware accelerated rendering seems to have. Bonus that it doesnt use any GPU resources in the age of AI
Michael Abrash's Graphics Programming Black Book is still one of my all time favourite. What they did back then was almost black magic. I learned a good part of maths, cs and physics trying to mod id1 with this book during my teenaghood.
That name brought back memories.
Unfortunately I didn’t do anything as impressive as modding a game; I read the book because the writing style itself was engaging and gripping like a novel.
Shoutout to https://www.jagregory.com/abrash-black-book/
The tech specifics covered have been out of use for decades. But, it's still a very fun read about thinking through the process of optimization.
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.
There's Quake-SRP (the Slop Rust Port), code here: https://github.com/terrapapagalli1516/quake-srp
Playable in the browser (shareware version): https://quake-srp.pages.dev/
It's a faithful port of Quake's original software renderer. Everything happens on the CPU, which made it easier to match the original exactly. In theory the same could be done on a GPU, but I think it would be harder and messier.
The trade-off with software renderer is that it's more code. With GLQuake much of the actual rendering work is handed off to OpenGL itself, i.e. the driver and the GPU. In the software renderer, the engine does all of that in its own code.
Sonic Mania (2017) actually uses software rendering to give it that retro look and feel.
Love seeing Blood mentioned, sometimes I feel like I'm the only one who played it
There are dozens of us! Dozens!!
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?
Is this why Doom is so portable?
yes
Did you use any coding app to support you building the app? In that case, witch one is the one you choose and why. Thank you.
Anyone wants to tell him about CRT's?
Now that will truly blow his mind, at least on this setup and older games.
Even the oldest and cheapest CRT monitor my family had was pretty pixel-accurate unless you were right at the edges. I was doing pixel art on it as a child and had no issues at all.
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.
Won't CRT's have significantly less latency and motion blur than an LCD... Oh yeah, and deeper blacks as you say.
It should be pretty obvious that you don't need a Core 2 Duo to run Quake, which worked fine on a Pentium and some of the faster 486s.
Its so interesting to me that back then we would have died for the graphics we have today, and now this retro look is being appreciated. I mean, it definitely has an aesthetic but its generally unappealing. I guess nothing is immune to nostalgia and pining for being at the age when we had less responsibilities and life seemed easier.
I guess thats one of the reasons of the success of Minecraft?
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.
Unreal Tournament also had a software renderer IIRC, with an interesting dithering effect.
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.
Similarly, I really did prefer Playstation graphics to N64 graphics.
"I prefer the hum of tube amps, they sound so much warmer"
(And I actually do like their sound, but I wouldn't want to be stuck with only tubes)
UE5's nanite uses software rendering, but it doesn't look pixelated, does not need a high end computer, and does not require DOS.
“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.
Its probably not correct to state this. Its probably a combination of how nanite itself is doing Lob, lightning etc.
A mix of software and gpu
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.
At this point words get blurry. Is using CUDA or a compute shader "software rendering" or not?
I call it "like software rendering". Its certainly software rendering in spirit since no fixed function rendering hardware is being used.
Yeah, it may not be in the spirit of 90s software rasterizing, but since you don't offload the transform, lighting, and rasterizing procedures to specialized hardware, you technically do it "with code". The parallelization goes against the spirit though.
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.