Programmable Shader Model for Thinking

[Photonamus]

The Programmable Shader Model for Thinking

How watching hardware evolve for thirty years taught me
to think about everything

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

─── ◆ ───

Pong Was Not a Computer

Here is something most people never think about. Pong had no processor. There was no CPU, no code, no software of any kind. It was a handful of logic gates wired together on a board that used the television's own electron beam as a clock. The ball was a counter. The paddles were counters. Collision detection was a few gates comparing counter values. When the beam's position matched the ball's counter, the signal went white. That was the entire game. The hardware was the game. There was nothing to reprogram because there was nothing programmed in the first place. You would have to physically rewire the board to make it do something different.

This is where the story starts, and most people skip right past it because it does not look like anything we would call a game today. But if you were actually there, and you paid attention, this is where the pattern begins.

─── ◆ ───

The Console Is a Hardware Engine

When the Atari 2600 came along in 1977, it introduced a real CPU — a MOS 6507 — alongside a custom chip called the TIA that handled video. But the TIA was barely a graphics chip. It could draw a background, two player sprites, two missiles, and a ball. Five objects total. Everything else had to be faked by the CPU in real time, synchronized to the television beam as it physically swept across the screen line by line. If you wanted more than two sprites visible, you had to wait for the beam to pass the first one, then rewrite the sprite data before it reached the spot where you needed the next one. Miss your timing by a few cycles and you got visual garbage on screen.

There was no frame buffer. The 2600 had 128 bytes of RAM. Not kilobytes. Bytes. The image on screen only existed in the moment the beam painted it, driven by code that was essentially a real-time control loop racing against analog television hardware.

This is what brute-forcing graphics through a CPU actually looked like. No dedicated rendering hardware doing the heavy lifting. Just a processor running flat out trying to keep up with the physical beam.

The NES changed this by adding a dedicated Picture Processing Unit — the PPU — that maintained its own memory, stored tile and sprite data, handled background scrolling, and did its own rendering pass independent of the CPU. Now the CPU's job shifted from "manually construct every scanline in real time" to "describe the scene and let the PPU draw it." The architectural split between game logic and rendering had begun.

But every console PPU was fixed-function. It drew tiles on a grid and sprites on top of them, with fixed palettes, fixed sizes, and fixed rules. You could not ask it to do anything it was not wired to do. Each console was a different opinion about what the hardware should be able to do, baked permanently into silicon. The console was not running a game engine. The console was the game engine.

─── ◆ ───

The PC Had No Such Luxury

While consoles had dedicated graphics hardware with specific capabilities, the PC had almost nothing. Through the late 1980s and into the mid 1990s, the VGA card was basically a dumb frame buffer — a block of memory that mapped to pixel output. The CPU had to calculate every single pixel and write it into that memory directly.

This is the era of Wolfenstein 3D and Doom. John Carmack wrote renderers that were pure software — the CPU determined what color every pixel should be, thirty-ish times per second, using clever math like BSP trees for visibility and vertical strip rendering for walls. The entire "engine" was a C program doing enough math fast enough to fill a 320 by 200 pixel buffer before the next refresh.

This is also where the concept of a game engine as a separable thing first crystallized. Doom's renderer, physics, map format, and entity system were licensed to other developers who built entirely different games on top of them. The engine was the machinery. The game was the content you fed into it. That separation had real commercial value, and it proved the two things could be decoupled.

Quake pushed the CPU-only approach to its absolute ceiling. True 3D polygons, full projection pipeline, perspective-correct texture mapping, real lighting. Software rendered on a Pentium. It worked, but it was brutal. That ceiling was real and everyone could feel it.

─── ◆ ───

So We Added Specialized Hardware Again

The 3dfx Voodoo showed up in 1996 and did exactly one thing: rasterize textured triangles with z-buffering in dedicated hardware. The CPU still handled all the game logic, geometry transformation, and scene management. But instead of the CPU also having to fill every pixel, it handed finished triangles to the Voodoo card and the Voodoo drew them. The performance difference was staggering.

This was the exact same move the console makers had made years earlier — offload the rendering to a chip that is purpose-built for that job. The industry went from specialized hardware to general-purpose CPU and back to specialized hardware because the general-purpose approach hit a wall. The Voodoo was conceptually the same thing as the NES PPU, just solving a much harder version of the problem.

But early GPUs were still fixed-function. The Voodoo did texture mapping and z-buffering and that was it. You could not change how it textured or how it lit. You configured the pipeline they gave you. You did not program it.

The real shift came around 2001 with programmable shaders. Instead of a fixed lighting equation baked into silicon, you could write small programs that ran on the GPU for every vertex and every pixel. The GPU stopped being a fixed rendering appliance and became a programmable parallel processor aimed at graphics. That is the era of Halo — the original Xbox had a custom Nvidia GPU with programmable shaders, and Halo used them for water, lighting, bump mapping, and effects that no fixed-function hardware could have produced.

─── ◆ ───

The Pattern

If you step back and look at the full arc, a clear pattern repeats itself. Hardwired logic with no separation between game and hardware. Then a CPU with minimal display hardware, brute-forcing the rendering in real time. Then a more capable fixed-function graphics chip handling the drawing while the CPU handles logic. Then the CPU doing everything again on PC because there was no graphics chip worth mentioning. Then a fixed-function GPU re-introduced to break through the performance wall. Then that GPU becoming programmable so it could handle novel rendering techniques instead of just the ones it was wired for. Then shaders becoming general-purpose compute. Then specialized tensor cores showing up inside the GPU for machine learning workloads — specialized hardware inside specialized hardware.

The cycle is: general-purpose hits a wall, specialized hardware breaks through it, that specialized hardware gradually becomes more programmable and general, until the next wall appears and the cycle repeats. The "engine" concept just migrates up the stack as the hardware takes on more responsibility. When the hardware was the game, there was no engine. When the CPU did everything, the engine was the software renderer. When the GPU took over rendering, the engine became the orchestration layer managing what the CPU and GPU each do.

I watched this entire progression happen in real time over the course of my life. I have an original Atari in a box ten feet from where I am sitting right now, stacked in a pile with a Virtual Boy, a SNES, a Super Scope 6, and a Genesis. I watched every graphics card generation from the Voodoo forward. In 1997 I was playing Ultima IX and it required that card to even run — for reasons that are completely obvious now. And to run it on modern hardware today you still need a Glide wrapper because the game was built for fixed-function hardware that no longer exists.

─── ◆ ───

The Shader Model for Thinking

Here is where it gets personal. I realized I followed the exact same evolutionary path in my own head.

I started with fixed-function specialization. Machining was its own domain. Lapidary was its own domain. Guitar building, audio production, hardware repair, computing — each one was a dedicated chip that did one job. I learned each one as its own separate thing with its own rules, materials, and techniques.

But over time I started noticing that the operations transfer even when the materials change. Tolerances in machining and tolerances in lapidary are the same concept on different substrates. Signal flow in audio and signal flow in electronics and data flow in software are the same structural pattern. I stopped learning domains and started extracting the underlying operations. And once I had those, I could apply them to anything new by swapping in the material properties.

That is the programmable shader model. A fixed-function pipeline says "I do this specific thing to this specific input." A programmable pipeline says "give me the input description and the constraints and I will write the program on the fly." I generalized myself from hardwired circuits into a programmable processor. The domains are just texture data. My reasoning is the shader code. And I write a new shader for every new problem because I learned the instruction set, not just specific programs.

The path dependency matters here. I could not have jumped straight to this. Nobody becomes a general-purpose systems thinker from scratch. I had to do the machining to internalize what precision means at a physical level. I had to build the guitar to understand how properties emerge from material choices and geometry. I had to do the audio work to internalize signal-to-noise as a universal concept. Each domain was a training run that burned a deeper pattern into my reasoning. The general model emerged from the specific ones, exactly the way programmable shaders only became possible because GPU architects spent years building fixed-function stages and understood what operations were fundamental enough to be worth making programmable.

─── ◆ ───

The Universal Principle

Once I had the generalized model, something clicked that I was not expecting. I noticed that every system I have ever worked with follows the same fundamental rule.

You are controlling the rise of energy within a system over time. You want to put maximum energy through the system as fast as you can. And thermal is the limit. That is the wall. Nothing gets an exemption from thermodynamics.

A CPU dies because the silicon hits junction temperature before the heatsink can pull the heat away. An engine throws a rod because combustion pressure exceeds what the material can handle at that cycle rate. A thin piece of steel burns through under a weld because the arc deposits energy faster than the surrounding metal can conduct it away. A speaker blows because the voice coil accumulates thermal energy faster than it can radiate. A circuit trace burns because current density exceeds what the copper cross-section can carry.

Every single one of these is the same equation. Energy in per unit time versus the system's ability to absorb, convert, and dissipate. The maximum useful work you can extract from any system is bounded by how fast you can remove the waste heat. An engine, a CPU, a weld, a speaker — they are all governed by the same thermodynamic reality. Chemical energy to mechanical work and waste heat. Electrical energy to computational work and waste heat. Thermal energy into a joint and waste heat into the surrounding material. The useful work is what you are after and the heat is the byproduct, and the rate at which you can remove it is the hard ceiling on performance.

From here the entire job of engineering reduces to one sentence: give me the specs of the system and I will tune it to the edge of the envelope. Tell me the material limits, the cooling capacity, the thermal ceiling, and I will push the controllable variables to the boundary defined by those constraints. That process is the same whether I am overclocking a CPU, tuning an engine, dialing in a weld, or setting up a signal chain. The recipe for maximum performance is always the same — push the energy and speed to the limits of what the system can safely handle.

─── ◆ ───

Blueprints and the Gatekeeping Problem

This generalized thinking style also explains why visual programming works for me and text code does not. Unreal Engine's Blueprint system strips the syntax layer out completely and gives you the system diagram directly. Nodes are operations. Wires are energy flow. You are not writing text that describes logic to a compiler — you are looking at the operations and connecting them. It is a schematic, and I already knew how to read schematics from hardware, wiring, and audio signal flow. Blueprints did not teach me a new skill. They gave me a coding interface that matched the way I already think.

My error profile in Blueprints proves the point. I do not get syntax errors because there is no syntax. What I get is a misrouted wire or a missing logical step — the exact equivalent of wiring a circuit wrong or forgetting a stage in a signal chain. Those are system errors, not language errors.

I can review text code for logical correctness in any language without knowing that language because I am not parsing syntax. I am tracing the logic. What does this function take in, what does it do with it, what comes out, does that make sense. That is the same process as looking at an engine and asking whether this intake path makes sense for the airflow this combustor needs. The language is irrelevant. The logic is the system. But I cannot troubleshoot a misplaced comma or a syntax violation because that is not my processor type.

And this is where the gatekeeping gets ugly. When Blueprints launched, Epic had an awkward time with the terminology. They understood that visual scripters were doing real programming — building functional systems with logic, state management, data flow, and optimization. But they could not quite call it programming on paper because the traditional definition requires writing text code. The community split over it. People who made bad projects in Blueprints were used as evidence that the tool itself was bad, as if nobody ever wrote terrible text code.

The same thing is happening now with AI-assisted development. Some people use AI tools without understanding the logic underneath and produce garbage. That garbage is then used to argue that the method is fundamentally flawed. But nobody applies that standard in reverse. Nobody walks into a welding shop, watches a programmer fail to lay a bead, and concludes that welding is a fake skill. The tool did not fail. The person using it did not understand the system they were building in.

The real issue is that the programming profession built part of its identity around the difficulty of the notation. The syntax is the barrier to entry, and that barrier is what makes the credential feel valuable. If you let people in who can do the logic but skip the syntax, it threatens people whose professional identity depends on being the ones who can translate intent into notation. The pushback was never really about capability. It was about protecting the moat.

─── ◆ ───

The Takeaway

There is a way of thinking where you stop learning systems as isolated domains and start seeing the underlying operations that every system shares. It takes years to get there because you need the raw data from enough different domains before the common thread becomes visible. You cannot force it. You need the dataset.

But once it clicks, you can look at any system — mechanical, electrical, computational, organizational — and see the same structural pattern: energy in, work out, waste heat managed, performance tuned to the edge of the thermal envelope. The materials change. The constraints change. The recipe does not.

I did not learn this from a textbook. I learned it by burning a piece of metal and paying attention.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━