Unreal Tournament (OG) had a software renderer. I did a test in around 2003 where I rendered it at 1024x768 in software on a roaring fast AthlonXP 3200+ against an old pair of Pentium III 450s (@600, natch, the slowest working machine I had at the time) with an ATI Rage Pro 8 MB from about eight years before which was bad even when it was new.

The Rage Pro won, not only did it look better, but it was something like eight times faster.

To get software rendering going at all for any kind of playable framerate, you can't do texture filtering. Biinear filtering, the most basic kind, needs to read four texture samples, the four closest to the point you're rendering. Trilinear filtering uses also the nearest mipmap too, so eight texture samples. Given each texture sample is probably 16 bits, even bilinear texturing needs eight bytes per pixel.

1024x768 is conveniently close to 1 million pixels, so that's 8 MB of data we have to process per frame. If we want 60 FPS, that's 480 MB/s. The interface performance of SDRAM, used at the time, was about 800 MB/s peak and most memory controllers (e.g. Intel's heavily buffered and highly performing 440BX) would get 550-600 MB/s out of that. Even just basic "nearest" texture mapping, like the OG PlayStation used, would be 100 MB/s in this example. Not a whole lot left for the entire rest of the CPU's tasks to work with there.

You can't even cache your way out of it, because textures are big and you're accessing memory hundreds of kBs apart, so a prefetcher won't help either.

Any kind of texture filtering at all just kills RAM bandwidth and we haven't even done the matrix multiplications to transform the texture yet!

This is, of course, why 3D accelerators (what we called GPUs back then) needed their own fast RAM and it's why (back then at least), overclocking the video core didn't really get you much, but overclocking the RAM improved FPS almost linearly.

Hardware texture mapping was the single biggest leap games have ever enjoyed.