TinyGPU v2.0 Works in Silicon, but Its Smallest-GPU Claim Faces a Bigger Test

Tom Hardware reports that TinyGPU v2.0 now works in physical silicon, turning roughly 240,000 transistors into an operating 3D graphics processor. Designer Pongsagon Vichit showed the chip producing graphics after its Tiny Tapeout manufacturing run. That changes the project from an FPGA experiment into a fabricated application-specific integrated circuit, or ASIC.

The result matters because fabrication exposes problems that software simulation and FPGA testing can hide. Clock behavior, signal timing, memory access, and board-level integration must all survive contact with physical hardware. Vichit's video indicates that the essential pipeline runs, although the available demonstration does not answer every performance or reliability question.

This is not a miniature challenger to Nvidia, AMD, or Intel. TinyGPU v2.0 renders deliberately modest scenes at low resolution and limited color depth. Its real opponent is the gap between an interesting FPGA prototype and repeatable working silicon. Crossing that gap gives the project technical value far beyond its frame rate.

The next question concerns TinyGPU v3.0. Vichit is developing a more programmable design with pixel-shader features and fixes for known v2.0 limitations. That roadmap raises the stakes because every added capability consumes logic, memory bandwidth, and verification effort.

Tom Hardware Says TinyGPU Survived Its Silicon Test

The important change is not that TinyGPU displays simple 3D graphics. It is that the fabricated chip reportedly does what its digital design promised.

Vichit previously tested TinyGPU v2.0 on a Basys3 FPGA board. An FPGA is a configurable chip that lets designers test hardware logic before committing it to a fixed layout. That stage showed that the architecture could render models, accept controller input, and drive a VGA display.

Fabricating an ASIC removes that flexibility. The logic becomes a physical arrangement of transistors and wires. A design flaw cannot be corrected by loading a new configuration into the same chip. Significant errors usually require another manufacturing run.

According to the August 4 silicon test report, the returned TinyGPU v2.0 silicon produced real graphics during testing. The report describes the result as a successful real-world demonstration following the Tiny Tapeout production run.

That evidence supports a narrower claim than a complete product qualification. A video can show that major functions operate under one tested setup. It does not establish manufacturing yield, voltage tolerance, long-duration stability, or performance across multiple samples.

Those distinctions matter in semiconductor reporting. Engineers often call the first returned version A0 silicon. Getting useful output from A0 is meaningful because many hardware errors become expensive after tapeout. Tapeout is the point when a completed chip layout enters manufacturing.

The demonstrated pipeline reportedly handles transformation, lighting, rasterization, and display output. Transformation converts model coordinates into positions for the screen. Rasterization determines which pixels belong to each triangle. Lighting adjusts a surface's visible color using the selected light direction.

The designer's project documentation describes a 25 MHz architecture using about 240,000 transistors in fabricated form. It supports models containing up to 1,000 triangles, although actual speed depends on scene complexity and enabled features.

The documented display target is 320 by 240 pixels with 4-bit color. Four-bit color provides 16 possible color values within the relevant palette scheme. That is extremely limited beside modern graphics, but sufficient for showing recognizable shaded or textured objects.

The project also relies on external QSPI memory. QSPI is a serial interface that transfers data across multiple signal lines. TinyGPU uses that external hardware for model data, frame storage, and depth information that would consume too much on-chip area.

Vichit's setup includes a VGA output module, QSPI hardware, a gamepad interface, and an SNES controller. Users can rotate models, change their scale, or adjust the directional light. Those controls make the demonstration interactive rather than a fixed animation burned into the circuit.

Tom Hardware previously covered the design before fabrication, when the reported transistor estimate was closer to 200,000. The current 240,000 figure reflects the fabricated implementation described by Vichit. Estimates can change as synthesis and physical layout translate source logic into actual standard cells.

The result therefore closes one uncertainty while leaving several others open. TinyGPU v2.0 is no longer only a simulation or FPGA claim. It is reportedly functioning silicon, but it remains an experimental chip rather than a qualified commercial GPU.

A 240,000-Transistor GPU Is Really a Study in Constraints

TinyGPU becomes interesting when its limitations are treated as design requirements, not embarrassing comparisons with desktop graphics cards.

A modern discrete GPU contains billions of transistors, extensive cache, specialized compute blocks, video engines, and large memory interfaces. TinyGPU v2.0 has none of that scale. Comparing their headline performance would reveal little about the engineering problem Vichit chose to solve.

His problem is compression. The architecture must preserve enough of a conventional graphics pipeline to transform and draw 3D geometry within a tiny logic budget. Every register, multiplier, buffer, and control state competes for the same limited silicon area.

Fixed-point arithmetic helps control that budget. Fixed-point numbers reserve predetermined bits for their integer and fractional portions. They need less circuitry than general floating-point operations, but designers must carefully manage range and precision.

The pipeline also uses flat shading with one dynamic directional light. Flat shading assigns a consistent lighting value across a triangle rather than calculating smooth changes for every vertex or pixel. That choice reduces computation while preserving visible 3D form.

Backface culling removes triangles facing away from the camera. Those surfaces normally cannot be seen, so skipping them saves rasterization work. It is a standard graphics technique whose benefit becomes especially important with a small transistor and clock budget.

An 8-bit depth buffer records which surface should appear in front at each location. Without depth testing, triangles drawn later could incorrectly cover nearer geometry. The limited precision suits these compact scenes, though it would be inadequate for many larger environments.

The 4-bit double buffer keeps separate drawing and display surfaces. One buffer can be shown while the next frame is prepared. Swapping them reduces visible tearing, where portions of two frames appear together during an update.

These features make TinyGPU v2.0 more than a hardwired pattern generator. The chip accepts model data and processes geometry through recognizable stages. However, it remains a fixed-function design with strict boundaries around scene size, output quality, and supported effects.

The reported frame-rate range reaches roughly 7.5 to 15 frames per second under appropriate scenes. The repository also documents a textured 1,000-triangle example at 6.5 FPS. Those figures describe different workloads, so they should not be treated as conflicting universal benchmarks.

Frame rate depends on triangle count, visible area, texture work, memory delays, and other scene details. A small object can require less pixel processing than geometry covering most of the display. Any serious comparison needs identical models, settings, clocks, and output conditions.

That benchmarking context is still incomplete. The silicon video confirms visible operation, but it does not provide a broad performance suite. It also does not establish whether every documented feature was exercised during the recorded test.

This is where the smallest-GPU label requires care. "GPU" has no single transistor threshold, and independent hobby projects implement different subsets of graphics functionality. Some draw only basic primitives, while others include transformation, textures, lighting, or programmable stages.

The title is therefore useful shorthand, not a standardized award. TinyGPU's more defensible distinction is its combination of fabricated silicon and a compact, self-contained 3D pipeline. Readers should evaluate the documented functions instead of relying on the superlative alone.

That combination also creates educational value. The source exposes the pipeline in Verilog, a hardware description language used to define digital circuits. Developers can inspect how graphics concepts become state machines, arithmetic units, and memory transactions.

For students, this makes familiar visual output a doorway into chip design. A spinning model is easier to interpret than an abstract waveform. Yet every visible frame still depends on the same timing, verification, and physical-design disciplines used in larger chips.

Tiny Tapeout Turns the Prototype Gap Into the Main Contest

TinyGPU's central victory is over the cost and coordination barrier that usually keeps small hardware projects away from fabricated silicon.

Chip fabrication normally favors organizations that can fill a large die and manage specialized engineering flows. A solo designer rarely needs an entire wafer. Even a tiny experimental circuit carries setup, packaging, validation, and manufacturing requirements.

The shared-wafer program changes that equation by placing many small designs on the same manufactured chip. Each contributor receives a defined tile area. Shared infrastructure handles common interfaces, selection logic, and access through a demonstration board.

This model resembles shared transportation. Every design occupies only part of the available vehicle, so no participant must fund the full trip. The analogy is imperfect, but it explains why multi-project wafers have become valuable for education and experimentation.

TinyGPU v2.0 uses a 4-by-4 allocation, equal to 16 Tiny Tapeout tiles. That is a large project within the platform's compact design model. The allocation still forces Vichit to make choices that a desktop GPU team would solve with vastly more silicon.

The program also imposes interface limits. External memory, video output, and controller input must pass through the available pins and supported add-on boards. These constraints shape the architecture as directly as the transistor count.

The process starts well before manufacturing. Vichit must describe the circuit in synthesizable Verilog, meaning code that tools can convert into real logic. Automated checks then verify interfaces, timing assumptions, and physical layout requirements.

Synthesis maps the design into a library of standard cells. Placement assigns physical locations to those cells. Routing connects them with metal traces while respecting manufacturing rules. The completed layout then joins other projects in the shared tapeout.

Simulation remains essential throughout that flow. A testbench supplies inputs and checks expected outputs before manufacturing. FPGA prototyping adds another layer by running similar logic on reconfigurable hardware with real peripherals.

Neither step perfectly predicts silicon. FPGA routing, memory blocks, and timing differ from an ASIC process. Physical chips also introduce clock, reset, power, and signal-integrity behavior that simplified tests might miss.

That is why working output after fabrication carries more weight than another FPGA video. The result indicates that the tool flow, shared platform, board connection, external memory, and graphics logic worked together. A failure in any critical link could have prevented a visible frame.

Tiny Tapeout's historical results provide useful context. Earlier runs have placed processors, signal generators, displays, accelerators, and experimental analog circuits into shared silicon. The platform is not dedicated to graphics, which makes TinyGPU a stress test for its general design model.

A graphics pipeline combines arithmetic, sequencing, memory traffic, and strict display timing. Losing synchronization can corrupt an entire image. Successfully coordinating these pieces makes the project a richer demonstration than a simple counter or blinking light.

Still, shared tapeout does not remove engineering risk. It redistributes infrastructure and reduces the entry barrier. Designers remain responsible for functional correctness, timing, resource use, and the behavior of their surrounding hardware.

The platform also cannot make a limited circuit behave like a larger one. TinyGPU's resolution, color depth, clock rate, and scene budget remain direct consequences of its design choices. Accessibility does not erase the relationship between area and capability.

The pressure therefore falls on traditional assumptions about who can fabricate an interesting processor. TinyGPU does not pressure Nvidia's product roadmap. It pressures the belief that custom graphics silicon belongs only inside large companies or university laboratories.

That shift has implications beyond GPUs. Small, open chips let developers test unusual accelerators, interfaces, and educational processors in their final physical medium. Some ideas will fail, but their failures can become visible and reproducible engineering evidence.

What the TinyGPU v2.0 Demonstration Does Not Prove

Working output establishes basic functionality, but it does not establish a complete benchmark, production readiness, or an undisputed world record.

The first uncertainty concerns the test scope. Public footage can show a model appearing on a monitor and responding to input. It cannot reveal whether every arithmetic path, memory condition, triangle orientation, or control state behaves correctly.

Comprehensive validation would require multiple test scenes and repeatable measurements. Reviewers would also need information about silicon samples, clock stability, voltage, temperature, resets, and long-duration operation. Those results have not accompanied the initial report.

The second uncertainty concerns performance. The quoted 7.5-to-15 FPS range appears consistent with earlier FPGA expectations, but workloads strongly influence the result. A benchmark needs a fixed model, camera, texture, viewport, and measurement method.

The chip's dependence on external QSPI memory further complicates interpretation. Memory latency can stall or pace different pipeline stages. The repository even documents adjustable latency settings for the attached memory module.

That does not weaken the project. External memory is a legitimate architectural choice, especially when on-chip storage would dominate area. It simply means the phrase "standalone GPU" should not be confused with a single component requiring no supporting hardware.

The GPU still needs memory, a clock, power, video connections, and input hardware. Commercial processors also depend on surrounding systems. Here, "standalone" means the graphics pipeline runs in fabricated logic rather than inside an FPGA or microcontroller.

The third uncertainty is the viewport failure documented by Vichit. In v2.0, geometry extending beyond the visible viewport can freeze the GPU and force a reset. A viewport defines the rectangular screen area where the scene should appear.

That is a substantial limitation for general 3D rendering. Cameras routinely move objects partly outside the screen. A graphics processor should clip or reject the relevant geometry without locking its pipeline.

Vichit says TinyGPU v3.0 addresses the problem. Until that version is published and tested, the fix remains part of the roadmap. The limitation also illustrates why programmable or flexible hardware increases verification demands.

A fourth concern involves the "world's smallest" description. Vichit's earlier first GPU design used about 16,000 gates and rendered only two textured triangles. Other tiny graphics circuits make different tradeoffs, making direct ranking difficult.

The earlier chip targeted 640 by 480 output at 60 FPS, which sounds faster than v2.0. However, it handled a radically smaller scene and lacked v2.0's capacity for model files containing up to 1,000 triangles.

This apparent reversal shows why one-dimensional comparisons fail. Higher resolution or frame rate does not automatically mean a more capable architecture. TinyGPU v2.0 accepts much richer geometry while operating at a lower display rate.

Modern GPUs present the opposite extreme. Their billions of transistors support massive parallel arithmetic, complex scheduling, programmable shaders, cache hierarchies, and high-bandwidth memory. TinyGPU intentionally removes most of those systems.

Nvidia's GeForce 256 offers a more relevant historical reference than a current gaming card. Introduced in 1999, it helped popularize hardware transformation and lighting as a defining GPU function. TinyGPU reproduces related concepts at an experimental scale.

However, shared terminology does not imply comparable breadth. GeForce-class hardware targeted commercial games, software compatibility, and sustained customer workloads. TinyGPU is an open learning project that illustrates selected mechanisms.

Tom Hardware appropriately frames the device as an enthusiast achievement rather than a purchasing alternative. The most useful reading follows that distinction. Its significance lies in visible silicon and architectural economy, not consumer performance.

The project would gain stronger evidence from reproducible test files, recorded clock conditions, and results from several chips. Independent builders could then compare hardware behavior with simulation and FPGA output.

Open source makes that process possible, but publication alone does not complete it. Source code permits inspection. Repeatable hardware testing turns inspection into stronger verification.

TinyGPU v3.0 Will Test Whether Programmability Fits the Same Tiny Envelope

The next version must add flexibility without losing the disciplined simplicity that allowed v2.0 to reach working silicon.

Vichit's public roadmap describes TinyGPU v3.0 as a move from a fixed pipeline toward programmable pixel processing. A pixel shader is a small program that calculates output color for pixels. It allows effects that fixed lighting and texture rules cannot express.

Public posts attributed to Vichit describe a design inspired by early DirectX 8 pixel shaders. The proposed core processes four pixels in parallel through single instruction, multiple data execution. SIMD applies one instruction across several data elements simultaneously.

The reported design uses a compact instruction set and a limited number of temporary registers. Masked execution provides a restricted method for handling conditional behavior. These choices aim to preserve programmability without importing the complexity of a modern shader architecture.

That is the mechanism worth watching. Programmability can replace several fixed circuits with reusable arithmetic and control logic. It can also require instruction storage, decoding, registers, scheduling, and more extensive hazard testing.

V3.0 must also solve the viewport problem. Vichit has discussed near-plane and far-plane rejection alongside guard-band clipping. Guard-band clipping permits coordinates beyond the visible area before later stages restrict pixels to the screen.

If that mechanism works, partially visible objects should stop freezing the processor. The improvement would make camera movement and general scenes more practical. It would also address a clearly documented v2.0 weakness rather than adding features for their own sake.

Three signals now matter most.

First, Vichit needs to publish a stable v3.0 architecture and synthesizable implementation. Feature descriptions can change while the logic is being optimized. A public repository would expose the actual instruction format, pipeline, and resource use.

Second, the design needs reproducible FPGA results using scenes that stress clipping and shader execution together. Maintaining frame rate during a simple effect is not enough. Tests should place geometry across screen boundaries while exercising depth and external memory.

Third, v3.0 eventually needs another silicon result. FPGA success would validate much of the logic, but the central lesson from v2.0 is that fabrication represents a separate threshold. Working A0 silicon would strengthen the new architecture's claims.

Failure at any stage would still produce useful information. Exceeding the tile budget would reveal the area cost of programmability. Timing problems would identify slow paths. Visual errors could expose precision or memory-ordering assumptions.

The roadmap therefore matters even if v3.0 misses a planned 2026 release window. Chip schedules depend on design readiness and shared manufacturing opportunities. A delay would be less informative than the reason behind it.

Readers should also resist treating v3.0 as an inevitable product line. There is no announced consumer market, driver ecosystem, or commercial software stack. The project currently functions as open hardware development and public experimentation.

That focus allows Vichit to make choices commercial GPU vendors cannot. Compatibility with existing games is unnecessary. Driver support can remain narrow. The design can favor transparency and visual education over general-purpose performance.

At the same time, programmability will invite tougher comparisons. Once a processor runs shader instructions, developers will ask about instruction limits, branching behavior, texture access, precision, and throughput. Each answer creates another verification obligation.

The v2.0 achievement gives that roadmap credibility because its predecessor reached silicon and reportedly produced graphics. It does not guarantee that v3.0 will fit, run, or fabricate successfully. Hardware progress remains cumulative but unforgiving.

For developers following Tom Hardware coverage, the best next step is to examine the open design rather than focus on the superlative. Compare the repository specification with future benchmarks, test scenes, and silicon footage.

TinyGPU's lasting value will depend on whether others can reproduce, study, and extend its techniques. A single successful demonstration creates attention. Documented verification turns that attention into reusable engineering knowledge.

Watch whether v3.0 preserves a clear relationship between each feature and its hardware cost. If shader flexibility, clipping, and parallel pixel work remain understandable, the project will retain its strongest advantage.

The smallest useful GPU is not necessarily the one with the fewest transistors. It is the one whose constraints expose how graphics hardware actually works. TinyGPU v2.0 has reached that point in silicon.

Now v3.0 must show whether the same clarity survives a more programmable pipeline. That test, rather than a contest with desktop GPUs, will determine the project's next chapter.