Hacker News

His definition of software rendering is

  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

yup, it should be renamed to "I Love GL_NEAREST_MIPMAP_NEAREST"

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?

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.

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.

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.

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.

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.

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.

I'm interested in hearing more

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.

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.

The difference in performance is just so big, unless you're targeting something without a GPU, there is no world in which you would want to leave it unutilized IMO, even if you're just rendering an UI. I can do things on my slow phone in WebGL that would stutter on my desktop if I drew the pixels with the CPU.

The thing is, back then CPU were super slow and more complex software renderers were actually not useable/available

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.

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.

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 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.

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.

Yes

Yes, although Doom isn't categorized as a real 3D engine as such.

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)

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.

There are dozens of us! Dozens!!

> 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?

yes

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.

I guess thats one of the reasons of the success of Minecraft?

Similarly, I really did prefer Playstation graphics to N64 graphics.

“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?

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.