Theme 1 – The pixelated look is about texture filtering, not the rendering method
Many commenters note that the “software‑rendered” aesthetic people love comes from using nearest‑neighbor texture sampling, which can be turned on or off regardless of whether the rasterizer runs on the CPU or GPU.
“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.” — ryandrake
Theme 2 – Software rendering gives debuggability and control; hardware rendering trades that for performance and hidden complexity
Software rasterizers let programmers step through the pipeline and see exactly why a pixel is wrong, while GPUs introduce driver quirks, shader‑compiler bugs, and opaque hardware behavior.
“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.” — coppercrisp62
Theme 3 – Pure software rendering is now impractical; modern OSes and hardware assume GPU acceleration
Today’s operating systems use the GPU for compositing, and blitting full‑screen frames directly to display buffers is no longer feasible in the strict sense, making real‑time software rendering largely obsolete outside of niche or offline uses.
“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.” — delta_p_delta_x