tinygrad maps GPU BARs in userspace for NVIDIA and AMD GPUs
George Hotz's AI stack still relies on Linux plumbing, but the code shows a serious attempt to move GPU control into a smaller runtime.
By Ryan Merket ยท Published
Why it matters
tinygrad's BAR-mapping work is an attempt to move more GPU control into an inspectable AI runtime, which could weaken vendor lock-in if it proves reliable beyond developer machines.
George Hotz (@realGeorgeHotz)'s tinygrad says it can map PCIe Base Address Registers directly for NVIDIA and AMD GPUs, a low-level runtime claim that puts the AI framework closer to the hardware than most developers ever get through PyTorch, JAX, CUDA or ROCm.
The claim appeared in a July 12 post on X:
But the date of the underlying implementation is not established from the post or the public materials reviewed. The current tinygrad documentation and code support the substance: tinygrad documents PCI interfaces for both AMD and NVIDIA, and its runtime source shows GPU resources being opened through Linux PCI sysfs paths and mapped into memory.
That distinction matters. tinygrad is not eliminating the operating system from the path. The code still depends on Linux mechanisms such as /sys/bus/pci/devices, file descriptors and mmap. What tinygrad is trying to avoid is exclusive dependence on the normal vendor driver API surface that defines how most AI software reaches GPUs.
Hotz has been building toward this fight since leaving the day-to-day work at comma.ai for what TechCrunch in November 2022 described as a new machine-learning framework and AI-compute project. In his own May 24, 2023 funding post, Hotz wrote that tiny corp's goal was "to commoditize the petaflop," then reduced the commercial plan to a simple hardware business: sell computers for more than they cost to make. That post also made the software thesis explicit. Hotz argued that AI chip startups had been hurt less by silicon ambition than by weak software, and wrote of AMD chips: "We are going to write our own software." (post)
What the code shows
The public tinygrad runtime docs list several backend paths. For AMD, tinygrad documents KFD, which uses the amdgpu driver, PCI, which uses tinygrad's AM driver, and USB for specific asm24xx chips. The same page warns that forcing AMD's PCI interface "may unbind your GPU from the amdgpu driver." For NVIDIA, tinygrad documents NVK, which uses the nvidia driver, and PCI, which uses tinygrad's NV driver.
The source code is more concrete than the docs. In tinygrad/runtime/support/system.py, the PCI device support scans Linux PCI devices, checks existing driver state through sysfs and works with PCI resources. In amdev.py, the AMD device initialization maps BAR0, BAR2 and BAR5. In nvdev.py, the NVIDIA device initialization maps BAR0 for MMIO and BAR1 for VRAM.
PCIe BARs are how a device exposes regions of memory or registers to the host. Mapping them gives software a way to read and write device-facing address spaces directly. In the GPU context, that is a serious commitment: the runtime has to manage device state, memory, page tables, firmware interactions and reset behavior that higher-level ML frameworks usually delegate to vendor stacks.
tinygrad's claim should be read as a systems architecture bet, not as a finished replacement for every production driver path. The AMD path has explicit warnings about unbinding from amdgpu. The NVIDIA path reaches into MMIO and VRAM mapping, but public code alone does not prove production stability across every Ampere, Ada or Blackwell configuration. That is the risk of going lower in the stack: the code gets more inspectable, and the maintenance burden gets harsher.
Hotz's old pattern, aimed at GPU software
Hotz built his reputation by finding lower layers than vendors wanted users to touch. Bloomberg's 2015 profile described him as the first person to hack the iPhone and as the hacker who later cracked the PlayStation 3 before turning to a garage-built self-driving car project. That history is relevant here because tinygrad is following the same pattern in a different market: move below the polished product boundary, build a smaller stack, then prove the stack can run real workloads.
The public tinygrad GitHub repo describes the project as an end-to-end deep learning stack with a tensor library, autograd, an IR and compiler, JIT and graph execution, and training utilities. GitHub showed about 33,000 stars and 4,200 forks when reviewed. The project positions itself between PyTorch's usability and micrograd's simplicity, with tiny corp maintaining it.
The company around it is real, though still lightly disclosed. A Form D filed with the SEC identifies tinygrad, Corp. as a Delaware corporation and lists George Francis Hotz as executive officer, director, president and CEO. The filing reports a $5 million offering sold to two investors, with a first sale date of May 23, 2023. Hotz's blog post the next day said tiny corp raised $5.1 million. Named investors and valuation were not disclosed in the filing or the post.
The business model remains tied to boxes, not enterprise software subscriptions. The tinygrad homepage says tiny corp sells tinybox machines in red, green and exa configurations. The current shop lists a tinybox red v2 at $12,000 with four Radeon 9070XT GPUs and a tinybox green v2 Blackwell at $75,000 with four RTX Pro 6000 Blackwell GPUs. An exabox preorder is listed at $100,000, with the full purchase price described as close to $10 million for a container-scale system.
That hardware business gives the BAR-mapping work a commercial reason to exist. tinygrad is not merely writing a hobby compiler for other people's clouds. It is selling machines where control of the runtime, drivers and framework can affect performance, margins, support load and the range of GPUs tiny corp can use.
The pressure point is CUDA's control layer
NVIDIA's strategic advantage in AI is frequently described as GPU supply, but the harder moat is software: CUDA, libraries, tools, kernel maturity and developer habit. AMD's recurring opening is hardware economics, yet the company's challenge in AI has often been the usability and maturity of the software stack around that hardware.
tinygrad is making the same market diagnosis from the bottom up. If a small runtime can drive AMD and NVIDIA GPUs through PCI paths, the framework gets a shot at portability that does not wait for every vendor layer to feel like CUDA. It also gives tinygrad a way to make its own hardware products feel less like commodity GPU boxes and more like an opinionated compute stack.
There is recent evidence that tiny corp wants to be judged in public benchmarks rather than only on code aesthetics. MLCommons announced MLPerf Training v6.0 results on June 16, 2026 and included tinycorp among the submitting organizations. That does not validate the BAR-mapping path specifically, but it shows tiny corp putting systems into the same benchmarking arena where vendor software usually dominates.
The open question is whether this low-level path can move from developer control to dependable training infrastructure. BAR mapping is powerful because it reduces the distance between a framework and the GPU. It is fragile for the same reason. Security boundaries, firmware revisions, kernel behavior, GPU resets and chip-specific quirks all become tinygrad's problem.
Hotz's bet is that a small, readable stack can absorb that pain and give AI builders another path through the compute market. The public code shows tinygrad is not waiting for the standard GPU software hierarchy to become more open. It is cutting below it, one mapped BAR at a time.