Silicon Deism — The Abstraction Elimination Thesis

There is only math, energy, and silicon. Everything else is an abstraction. Three phases from vendor agnostic to silicon deistic.

Thesis

There is only math, energy, and silicon. Everything else is an abstraction.


Three Phases

Phase 1: Vendor Agnostic (Achieved)

Math -> Rust -> WGSL -> wgpu -> vendor driver -> GPU

The computation is expressed in vendor-neutral shader language (WGSL). The wgpu runtime maps to Vulkan, Metal, or DX12 depending on platform. The vendor driver translates to hardware instructions. Any GPU from any vendor runs the same math.

What this means: barraCuda molecular dynamics produces bit-identical results on NVIDIA (Volta, Turing, Ampere, Ada, Blackwell), AMD (RDNA2, CDNA), and Intel (Arc) GPUs. The science does not depend on the vendor.

Phase 2: Vendor Atheistic (In Progress)

Math -> Rust -> WGSL -> coralReef -> toadStool (VFIO) -> GPU

coralReef compiles WGSL to native GPU ISA without vendor toolchains (no CUDA, no ROCm, no oneAPI). ToadStool manages GPU access via VFIO passthrough — the kernel provides PCI access, not a vendor driver stack.

What this means: No proprietary compiler in the pipeline. No vendor runtime. The shader goes from Rust source to native machine code through sovereign tooling.

Phase 3: Silicon Deistic (Target)

Math -> Rust binary -> native ISA -> transistors

No runtime. No driver. No firmware abstraction. The binary talks to the silicon. The computation is math, the medium is energy, the substrate is silicon. Everything between math and transistors is eliminated.

What this means: The firmware wall — boot ROM, microcontroller firmware, power gating logic — is the last barrier. Crossing it requires either reverse-engineering PMU mailbox protocols or building hardware with open firmware.


Why Rust Matters Here

Rust’s compile-time guarantees mean the abstraction elimination is safe:

  • No runtime — Rust compiles to native code with no garbage collector, no VM, no interpreter. One fewer abstraction layer.
  • Compile-time dispatch — generic monomorphization means the compiled binary is specialized for the target. No runtime type dispatch.
  • Unsafe confined to silicon boundary — unsafe code exists only at the hardware interface (MMIO, DMA). Everything above is type-checked.

Concrete Example: Wilson Plaquette

For a Wilson plaquette computation in lattice QCD:

LayerSovereignty
Equation (Wilson action)Sovereign — math is public
Rust implementationSovereign — AGPL-3.0
WGSL shaderSovereign — coralReef compiles
ToadStool dispatchSovereign — VFIO passthrough
Vendor driverNot sovereign — black box (Phase 2 eliminates)
GPU firmwareNot sovereign — the wall (Phase 3 eliminates)

The plaquette observable — a physical quantity — is the same regardless of which layers are sovereign. But the trust is different: with full sovereignty, you can verify every step from equation to silicon. Without it, you trust that the vendor’s driver and firmware do not alter the computation.


The Firmware Wall

The last abstraction before silicon. Three paths forward:

  1. PMU Mailbox (most promising) — communicate with the GPU power management unit directly to control compute domains without vendor firmware mediation.
  2. Open firmware — hardware designs with fully open boot sequences (RISC-V GPU projects, open FPGA toolchains).
  3. Accept the wall — for most science, Phase 2 (vendor atheistic) is sufficient. The firmware does not alter computation; it manages power and scheduling. Trust but verify through cross-vendor bit-identical results.

Sovereignty Tier Model

TierNameStatus
0Cold (vendor wall)Identified
1Warm InfrastructureValidatedcellMembrane, Songbird, BearDog
2Warm ComputeBlocked by GPU power domain firmware
3Full Sovereign (silicon deism)Requires open firmware or PMU bypass

Philosophical Note

The vendor is the watchmaker. The silicon is the watch. Silicon deism does not reject the watchmaker — it honors the watch by using it directly.

The vendor built extraordinary hardware. The abstraction elimination thesis says: let us use it fully, without intermediary, with the math touching the silicon as directly as the physics allows.


guideStone asks: “does this machine have silicon that can compute?” Not “does it have the right driver?” Not “does it have the right license?” The verification class operates at the level of math and silicon. Everything between is convenience — useful, sometimes necessary, but never the truth.