GoGPU vs Born: In-Depth Comparison Report

Two flagship projects in the pure-Go GPU ecosystem: a low-level graphics framework versus a high-level deep learning framework.

Tags: GoGPU v0.41.9 · Born v0.9.1 · Shared Ecosystem

Ecosystem Relationship Diagram

• gogpu/wgpu — Pure-Go WebGPU implementation (foundation layer)
• gogpu (App) — Graphics rendering, window management, input
• Born — Deep learning, LLM inference

Born's WebGPU backend directly depends on gogpu/wgpu — the two share the same origin but occupy different architectural layers.

GPU backends supported via gogpu/wgpu: Vulkan, DX12, Metal, GLES.

1. Overview Comparison

| Dimension | GoGPU | Born | |---|---|---| | Project positioning | Pure-Go GPU graphics/compute framework (low-level engine) | Pure-Go deep learning framework (high-level application framework) | | Inspiration | Ebiten / Gio game engine architecture | Burn (Rust) + PyTorch + TinyGrad | | Core philosophy | "GPU power, Go simplicity. Zero CGO." | "Models are born production-ready." | | GitHub Stars | 305 ⭐ | 97 ⭐ | | Releases | 163 | 35 | | Commits | 265 | 105 | | License | MIT | Apache-2.0 | | Go version requirement | Go 1.25+ | Go 1.26+ | | Language composition | Go 99.4% | Go 99.2% | | Open Issues | 6 | 1 | | Watch / Fork | 4 / 10 | — / 7 | | Latest version | v0.41.9 (2026-06-11) | v0.9.1 (2026-05-27) |

2. Technical Architecture Comparison

| Dimension | GoGPU | Born | |---|---|---| | Core abstraction | App → Renderer → hal.Device/Queue | Backend → Tensor → Autodiff → Optimizer | | Design pattern | Multi-threaded (event main thread + dedicated render thread) | Decorator pattern (Backend → Autodiff → Fusion) | | Thread model | Ebiten/Gio style: main thread handles window events, render thread owns GPU operations | No specific thread model; abstracted via Backend interface | | GPU backends | Pure Go (default), Rust FFI (-tags rust), Browser WASM | CPU (pure Go), WebGPU (via gogpu/wgpu); planned: Vulkan/CUDA/Metal | | Graphics APIs | Vulkan, DX12, Metal, GLES, Software (runtime selection) | WebGPU only (via gogpu/wgpu) currently | | Platform support | Windows, Linux (X11/Wayland), macOS, Browser/WASM | Windows (DX12); Linux/macOS planned | | CGO dependency | Zero (default Pure Go) | Zero | | Type system | Concrete types (primarily float32) | Go generics (Tensor[DType, Backend]) | | Resource management | TrackResource auto-cleanup + runtime.AddCleanup GC safety net | runtime.SetFinalizer for GPU buffer cleanup |

3. Core Capability Comparison

GoGPU-Exclusive Capabilities

🎨 Graphics Rendering

• Zero-copy surface rendering (SurfaceView)
• Event-driven three-state rendering (idle/animating/continuous)
• Texture loading (PNG/JPEG/Go image)
• Triangle drawing, shader pipelines

🪟 Window and Input

• Native window management (Win32/Cocoa/X11/Wayland)
• Centralized input event queue (keyboard/mouse/scroll)
• Game-style input polling (JustPressed/Pressed)
• Multi-window support + WindowID tagging
• HiDPI, cursor modes (locked/confined/normal)

🔧 Platform Integration

• macOS system menu (NSMenu)
• System sound effects (Click/Alert/Error, etc.)
• Clipboard read/write
• Dark mode / reduced motion / high contrast detection
• Borderless windows + DWM shadows

Born-Exclusive Capabilities

🧠 Deep Learning Core

• Automatic differentiation (decorator pattern)
• 38+ WebGPU-accelerated operators
• CNN (Conv2D, MaxPool2D)
• Optimizers (Adam, etc.)
• Loss functions (CrossEntropyLoss, etc.)
• Lazy evaluation + command batching

🤖 Transformer / LLM

• Flash Attention 2 (O(N) memory)
• Speculative decoding (2–4x speedup)
• KV-Cache (3.94x speedup)
• MHA / SDPA / GQA attention
• RoPE / ALiBi / Sinusoidal positional encoding
• SwiGLU / GeGLU / ReGLU FFN

📦 Model Ecosystem

• ONNX import (49 operators)
• GGUF import (Q4_K / Q5_K / Q6_K / Q8_0)
• End-to-end LLaMA inference (verified TinyLlama 1.1B)
• SafeTensors export (HuggingFace compatible)
• TikToken / BPE tokenizer
• Temperature / Top-K / Top-P / Min-P sampling

Shared Capabilities

🔬 GPU Compute

• Compute shader support
• WebGPU standard API
• Pure-Go implementation, zero CGO
• Cross-platform GPU acceleration

🌐 Cross-platform

• Windows support (DX12)
• Linux support (Vulkan)
• macOS support (Metal)
• WASM browser support

📐 Math Libraries

• Vector/matrix operations
• GPU-accelerated matrix multiplication
• Tensor operations

4. Performance

Born WebGPU Acceleration (RTX 3080)

| Operation | CPU | GPU (WebGPU) | Speedup | |---|---|---|---| | MatMul 1024×1024 | 7143ms | 58ms | 123× | | MatMul 512×512 | 499ms | 12ms | 41× | | MatMul 256×256 | 56ms | 3.7ms | 15× | | NN inference (batch=64) | 48ms | 19ms | 2.5× | | NN inference (batch=256) | 182ms | 21ms | 8.5× | | NN inference (batch=512) | 348ms | 32ms | 10.9× |

GoGPU Rendering Performance Characteristics

| State | CPU Usage | Frame Rate | Use Case | |---|---|---|---| | Idle | 0% | Blocks on OS events | UI apps without animation | | Animating | Low | VSync (~60fps) | UI animations, transitions | | Continuous | 100% | Unlimited | Game loops, real-time rendering |

> Key Performance Insight: Born's GPU acceleration comes from the underlying gogpu/wgpu WebGPU implementation. The 123× MatMul speedup proves the Go + WebGPU combination delivers production-grade matrix performance. GoGPU's three-state rendering model achieves fine-grained power control from 0% CPU (idle) to 100% CPU (game loop) — a unique optimization at the graphics-framework level.

5. Community and Maturity

• Iteration speed: GoGPU 163 releases vs Born 35
• Community attention: GoGPU 305 ⭐ vs Born 97 ⭐
• Code volume: GoGPU ~100K lines vs Born (substantial)
• GPU backend count: GoGPU 5 APIs vs Born 2 (CPU + WebGPU)
• Platform coverage: GoGPU all platforms vs Born Windows-first
• Documentation completeness: GoGPU ahead of Born

6. Documentation and Developer Experience

| Dimension | GoGPU | Born | |---|---|---| | API docs | Full pkg.go.dev reference | Full pkg.go.dev reference | | Architecture docs | ARCHITECTURE.md (with ADRs) | PHILOSOPHY.md, USE_CASES.md | | Roadmap | ROADMAP.md | ROADMAP.md | | Getting started | ~20 lines of code to render a triangle | MNIST training + LLaMA inference examples | | Sample code | Compute shaders, multi-window, input polling, texture loading | MNIST, LLaMA inference, GPU backend selection | | Design decisions | ADR records (e.g., ADR-026 window lifecycle) | Design philosophy document | | External articles | 2 dev.to articles (100K-line dev journey) | — | | Tech blog | Development narrative available | Limited |

7. Roadmap and Future Direction

GoGPU Roadmap

• ✅ Multi-backend architecture (Vulkan/DX12/Metal/GLES)
• ✅ Pure Go / Rust FFI / WASM tri-backend
• 🔵 Planned: gogpu/ui — GUI toolkit
• 🔵 Planned: Continued 2D/3D graphics improvements
• 🎯 v1.0 — API freeze, long-term support

Born Roadmap

• ✅ CPU + WebGPU backends
• 🟠 Planned: Vulkan / CUDA / Metal backends
• 🟠 Planned: GPTQ / AWQ quantization
• 🟠 Planned: PagedAttention + continuous batching
• 🟠 Planned: OpenAI-compatible API
• 🎯 v1.0 LTS — API freeze, 3+ year long-term support

> Ecosystem Synergy Outlook: Born's planned Vulkan/CUDA/Metal backends will further depend on the GoGPU ecosystem (gogpu/wgpu, gogpu/naga). As Born moves toward v1.0, the symbiotic relationship tightens — GoGPU provides cross-platform GPU primitives, Born builds production-grade deep learning services on top.

8. Use-Case Fit Matrix

| Scenario | GoGPU | Born | |---|---|---| | Game engine development | ✅ Core use case | ❌ N/A | | GUI applications | ✅ Core use case | ❌ N/A | | 2D/3D visualization | ✅ Core use case | ❌ N/A | | General GPU compute | ✅ Supported | ✅ Supported | | Deep learning training | ❌ N/A | ✅ Core use case | | LLM inference deployment | Limited | ✅ Core use case | | Scientific simulation | ✅ Compute shaders | ✅ Autodiff + operators | | WebGPU browser apps | ✅ WASM target | ✅ WebGPU backend |

Verdict

Choose GoGPU when:

• Building game engines, GUI applications, or visualization tools
• You need native window management and input handling
• You want cross-platform graphics APIs (Vulkan/DX12/Metal/GLES)
• You need fine-grained CPU power control (idle → continuous rendering)
• Your project is graphics-first

Choose Born when:

• Building deep learning models or LLM inference services
• You need automatic differentiation and optimization
• You want WebGPU-accelerated tensor operations in pure Go
• You plan to deploy models with ONNX/GGUF import workflows
• Your project is ML-first

Key Takeaways

• Shared foundation: Both projects leverage gogpu/wgpu, making them complementary rather than competing at the same layer.
• Zero CGO: Both achieve pure-Go GPU compute without CGO dependencies, simplifying deployment.
• Different maturity stages: GoGPU is more mature (163 releases, 5 backends, all platforms); Born is younger but rapidly evolving toward v1.0 LTS.
• Performance evidence: Born's 123× MatMul speedup validates pure-Go + WebGPU for production deep learning workloads.
• Ecosystem synergy: The two projects strengthen each other — GoGPU handles GPU primitives, Born handles ML abstractions.

*Report based on GoGPU v0.41.9 (2026-06-11) and Born v0.9.1 (2026-05-27). All metrics reflect publicly available repository data at time of writing.*