RFC: Pure Go GPU Driver (neon) — Direct Hardware Access

[kolkov]

RFC: Pure Go GPU Driver (neon) — Direct Hardware Access

Summary

We're exploring a new direction for the GoGPU ecosystem: a Pure Go GPU user-mode driver that talks directly to GPU hardware via kernel interfaces, bypassing Vulkan/Metal/DX12 entirely. This would be the first GPU user-mode driver written in Go in the world.

Motivation

GoGPU already has a Pure Go WebGPU implementation (wgpu) with 5 HAL backends. But all of them sit on top of existing GPU APIs:

Current:   Go app → wgpu → Vulkan/Metal/DX12/GLES → vendor UMD (C/Rust) → kernel driver → GPU
Proposed:  Go app → wgpu → neon (Pure Go UMD) → kernel driver → GPU

We replace the User-Mode Driver (Mesa NVK/RADV/ANV), not the kernel driver. The kernel driver (amdgpu, i915, nouveau) stays — it handles hardware init, scheduling, power management.

Why?

• Zero external runtime dependency — no libvulkan, no Mesa, no Metal framework needed
• Embedded Linux — bare-metal GPU access without full Vulkan/Mesa stack
• Pure Go philosophy — gogpu = full-stack GPU ecosystem, top to bottom
• Deep GPU understanding — benefits all existing backends
• Unique — nothing like this exists in the Go ecosystem

Research

We analyzed Mesa's open-source GPU drivers (NVK for NVIDIA, RADV for AMD, ANV for Intel). Measured LOC with wc -l on actual source:

Layer	NVK (NVIDIA)	Go Feasibility
Kernel interface (DRM ioctls)	~1.5K	Easy — syscall wrappers
Vulkan driver (command encoding + state)	34K	Hard — vendor-specific binary protocols
Shader compiler (NAK, Rust)	60K	Very hard — proprietary instruction sets

Full driver comparison (measured):

Driver	Vulkan LOC	Shader Compiler	Total
NVK (NVIDIA)	34K C	60K Rust (NAK)	~94K
RADV (AMD)	112K C	ACO (separate)	112K+
ANV (Intel)	102K C	brw (separate)	102K+

Scope clarification:

• Full driver + shader compiler: ~95-115K per vendor
• Driver without shader compiler (pre-compiled shaders): ~35-112K per vendor
• Compute-only MVP (single vendor): ~10-30K

Platform Support

Platform	Path	Status
Linux	DRM (/dev/dri/renderD128)	Fully open — standard ioctl interface
macOS (eGPU)	DriverKit for external PCIe GPUs	Compute-only. TinyGPU demonstrated May 2025 (SIP off), Apple-signed March 2026. AMD RDNA3+ / NVIDIA Ampere+ via Thunderbolt 4. No Metal API — direct compute.
macOS (Apple Silicon)	IOKit private API	Apple GPU ISA reverse-engineered by Asahi Linux (M1/M2/M3). On Linux: full DRM driver. On macOS: Metal uses IOGPUDeviceUserClient (IOKit) internally for GPU command submit. Mesa wraps IOKit entrypoints for AGX on macOS (wrap.dylib). Path exists but via private API — risky (Apple can break), no stability guarantee.
Windows	D3DKMT	D3DKMTSubmitCommand allows userspace command submission on GPU VA contexts. Vendor-specific command format still required.

GPU Vendor ISA Documentation

Vendor	ISA Documentation	Notes
Intel	Fully documented (PRMs)	Best first target
AMD	Partially documented (PAL, radeonsi)	Large open-source community
NVIDIA	Undocumented (reverse-engineered by Mesa NAK, Rust)	Hardest target
Apple	Reverse-engineered by Asahi Linux	M1/M2/M3. Full driver on Linux. macOS: IOKit private API path exists (Mesa wrap.dylib)

Existing Go DRM Libraries

Several Go libraries have wrapped DRM ioctls, but all are KMS/modesetting only — none do GPU command submission:

Library	Status	Notes
emersion/go-drm	Deprecated/migrated	By Simon Ser (wlroots/Mesa maintainer). Author disclaimer: "this project is silly"
NeowayLabs/drm	Stale since 2019	Pure Go (~1.7K LOC), proves ioctl mechanism works without CGO

The ioctl mechanism is proven in Go — NeowayLabs/drm uses pure syscall calls, zero CGO. ~1.7K LOC confirms our estimate for kernel interface layer.

Proposed Approach

Phased Development

Phase 0: Foundation

• Go DRM ioctl wrappers (GPU discovery, buffer allocation, memory mapping)
• Choose first vendor: Intel (best documented) or AMD (open register specs)
• Target: compute-only (dispatch shader, read result)

Phase 1: Compute MVP

• Command stream generation (PM4 for AMD / batch buffer for Intel)
• Pre-compiled shader binary loading
• Buffer → dispatch → readback pipeline
• Benchmark vs Vulkan path

Phase 2: Shader Compilation

• naga backend targeting native GPU ISA
• WGSL → GPU machine code (register allocation, instruction scheduling)

Phase 3: Rendering

• Vertex/fragment pipeline
• Rasterization, depth/stencil, blending
• Surface presentation via DRM/KMS

Repository

Start as a new HAL backend in wgpu (hal/drm/ or similar), extract to separate repo when mature. Working name: neon.

Estimated Effort

Milestone	LOC	Timeline
Compute-only MVP (single vendor, pre-compiled shaders)	10K–30K	3–6 months
Full rendering without shader compiler (single vendor)	35K–110K	1–2 years
Add shader compiler (naga ISA backend)	+30K–60K	6–12 months
Multi-vendor	150K–300K	2–4 years

GoGPU is already 1.1M+ LOC of Pure Go. Adding 30-100K for a GPU driver is ambitious but tractable.

Questions for Discussion

1. Which vendor first? Intel (best docs) vs AMD (bigger community) vs Apple Silicon (Asahi ISA available, Linux only)?

2. Separate repo from the start? Or incubate inside wgpu as hal/drm/?

3. Name? Candidates: neon, forge, warp, photon, nova, apex, aurora. Open to suggestions.

4. Who wants to help? GPU driver experience, DRM knowledge, shader compiler expertise — all valuable.

5. Is this worth doing? Vulkan already works. The value is in the journey (deep GPU understanding, Pure Go purity, embedded use cases) as much as the destination.

---

Tagging active ecosystem contributors for input:

@lkmavi @z46-dev @jdbann @k-chimi @georgebuilds @omer316 @unxed @TuSKan @adamsanclemente @darkliquid

We'd love to hear your thoughts — especially on vendor choice, naming, and whether you'd be interested in contributing to specific parts (DRM ioctls, shader compiler, macOS DriverKit, etc.).

References

• Mesa NVK — open-source NVIDIA Vulkan driver (34K C + 60K Rust)
• Mesa RADV — open-source AMD Vulkan driver (112K C)
• Asahi Linux GPU — reverse-engineered Apple GPU driver (Linux on Apple Silicon)
• Intel PRMs — GPU ISA documentation
• AMD PAL — Platform Abstraction Layer
• TinyGPU — DriverKit eGPU on macOS (compute-only, Apple-signed March 2026)
• NeowayLabs/drm — Pure Go DRM library (~1.7K LOC, KMS only, proves ioctl mechanism)
• D3DKMTSubmitCommand — Windows userspace command submission

[unxed]

Ого! Огромный объем же. Если для всех видях всех производителей

[kolkov]

Great question! To clarify what exactly neon would replace:

Current stack:
  Go app → wgpu → Vulkan API → Mesa User-Mode Driver (C/Rust) → Kernel Driver → GPU

With neon:
  Go app → wgpu → neon (Pure Go User-Mode Driver) → Kernel Driver → GPU

We're replacing the User-Mode Driver (Mesa's NVK/RADV/ANV) — not the kernel driver. The kernel driver stays as-is (amdgpu, i915, nouveau are built into the Linux kernel). We talk to it via standard DRM ioctls — a stable public interface.

Think of it like this: Mesa is ~6M LOC that implements OpenGL + Vulkan + everything. We only need the WebGPU subset — command buffer construction, memory management, shader compilation to GPU ISA. That's ~30-50K LOC per vendor (based on our NVK analysis).

The scope is large but tractable with a phased approach:

• Phase 0: DRM ioctls from Go (proven — several Go DRM libraries exist)
• Phase 1: Compute-only MVP on one vendor (~10-30K LOC)
• Phase 2: Shader compiler (naga backend for GPU ISA)
• Phase 3: Full rendering

Starting with Intel (fully documented ISA via PRMs) or AMD (open register specs) — not NVIDIA (undocumented ISA).

GoGPU is already 1.1M+ LOC of Pure Go — wgpu, naga, gg, ui, gogpu, and more. Adding 30-50K for a GPU driver backend is not that scary for us at this point 😊

[omer316]

My own opinion: No.

In details

First I should say that I'm not coming from a background of graphics infrastructure development. However, I do have experience of several decades of software development. In this regard I view the gogpu projects more from a user perspective (i.e., software developer that uses gogpu) than a developer perspective (that actively develops gogpu) .

Please don't take my opinion personally or as an insult. I wouldn't be here if I thought that the project isn't great.

So why do I say "no"?

1. gogpu projects are yet to achieve maturity. There are numerous obvious bugs, missing features and so on.
2. We are still missing broad examples, documentation and a website.
3. Once the current projects will reach their v1.0 state, they will still need to go via rigorous wide field testing.
4. The projects need to achieve the following states: they just work and they are done correctly

These (1-4) reasons will require a lot of development time. It's a long process but it's a must in order to gain trust from the users. We must make sure that anyone who wish to develop using gogpu will have a friction-less experience.

5. The suggested project has the indicators of: "it is going to be far more complex than what we currently think". - While, as I said, I'm not coming from graphics infra development background, I do know enough to know that this is a very hard problem and new problems (that currently don't exist) will rise in the near future as new graphic cards hit the market.
6. For regular users the benefit will be marginal.
7. The embedded scene isn't the one in which golang shines. Hard real-time OS's don't use go (mostly due to the GC) and in most cases where Linux is used dependencies can be installed or already available.
8. Embedded scenarios in which it will be beneficial are very likely to be sources for unique set of problems which will require too much attention in order to address.

Summary

I think the project needs to focus on completing its base features and do so in a spectacular way before progressing to a new content.

[kolkov]

@omer316 Thank you for the thoughtful and honest feedback — this is exactly the kind of input we need.

You're right on all counts about priorities. Let me clarify:

neon is research, not a redirection. The core roadmap stays exactly as you described:

1. v1.0 first — gogpu, wgpu, gg, ui reaching maturity with documentation, examples, website, and field testing. That's the priority.
2. "It just works" — bug fixes, missing features, friction-less developer experience. This is where the bulk of our effort goes.
3. neon = long-term research — a backlog item rated P3 (lowest priority). We've done initial research and published this RFC to gather community input, but driver implementation is a multi-year effort that runs parallel to — not instead of — core work.

Your point about complexity is especially valid — GPU drivers are notoriously hard, and we should only attempt this from a position of strength (mature ecosystem, proven track record, community of contributors), not as a distraction.

One clarification on points 6-8: neon is a user-mode driver (like Mesa NVK/RADV), not a kernel driver. It runs in regular userspace — Go's GC is not an issue here (same as our existing wgpu). The benefit for regular users would be concrete: go build produces a binary with GPU acceleration and zero system dependencies — no Mesa, no libvulkan, no driver packages to install. That said, whether this benefit justifies the effort is a fair question we'll evaluate carefully.

Thank you for keeping us grounded. The base features come first. 🙏

[z46-dev]

I think as I was reading this, I had a lot of thoughts that echoed what @omer316 is saying here. I'm only approaching a decade of software engineering, but it seems like it would be an incredible amount of effort to put in before the ecosystem is flushed out entirely in its structure. That being said, it would be a very good research topic, and could be done in later months/years once there is more documentation and examples, as well as a decent size of community projects using gogpu.

These are just my thoughts, so feel free to disagree.

[kolkov]

Design direction update.

After deeper study of modern GPU hardware capabilities, we're increasingly confident that Neon can be significantly simpler than Mesa — not just "Mesa rewritten in Go", but a fundamentally leaner architecture.

Why simpler

Modern GPUs (AMD RDNA 2019+, Intel Xe 2020+, Apple M1+ 2020+) have converged in ways that make large parts of Vulkan/DX12 API complexity unnecessary at the hardware level:

• Coherent L2 caches — the GPU command processor, ROPs, and compute units all see the same memory through L2. Per-resource barrier tracking exists in the driver, not in hardware. Neon can use stage-only synchronization (compute → pixel, color-out → pixel) instead of tracking every buffer and texture individually.
• Resizable BAR / Smart Access Memory — CPU can map full GPU VRAM. Memory allocation becomes GEM_CREATE + mmap → pointer. No complex heap management needed for the common case.
• Bindless descriptors — hardware descriptor heaps are just arrays of 256-bit blobs in mapped memory. Write a descriptor, pass the base pointer to the shader. No descriptor set layout/pool/allocation machinery.
• VK_KHR_unified_image_layouts (Vulkan 2025) — even Vulkan is acknowledging that image layout transitions are driver overhead, not hardware requirements. Neon can skip them entirely.

What this means for Neon's scope

Instead of implementing the full Vulkan API surface (~600 functions, ~200 structs), Neon targets a much smaller primitive set:

Primitive	Implementation
Memory allocation	GEM buffer create + mmap via DRM ioctl
Data binding	Direct descriptor heap writes to mapped memory
Synchronization	Stage-based barriers + DRM syncobj with timeline
Command submission	GPU command stream (PM4 on AMD, MI on Intel)
Shader compilation	naga → GPU ISA (RDNA or Intel EU instructions)

This is roughly the surface that Sebastian Aaltonen describes as "No Graphics API" — the minimal abstraction that maps directly to what GPUs actually do. CUDA proved this model works at scale for compute; Neon aims to prove it works for graphics too.

Hardware scope

We're not trying to support 20 years of GPU hardware. Minimum requirements:

• AMD: RDNA or newer (coherent L2, bindless)
• Intel: Xe or newer
• Apple: M1+ (via DriverKit, future phase)

Pre-RDNA AMD (GCN), pre-Xe Intel, and NVIDIA (proprietary ISA) are explicitly out of scope. First target remains AMD RDNA — open register specs, ACO shader compiler reference in Mesa, simpler PM4 command stream.

Timeline

This remains a post-v1.0 research project. Our v1.0 (December 2026) ships with Vulkan/DX12/Metal/GLES/Software backends. Neon is the long-term play for truly zero-dependency GPU access.

[TimLai666]

I think Neon could be introduced incrementally rather than treated as an all-or-nothing replacement for the existing wgpu backends.

The existing Vulkan, DX12, Metal, GLES, and software backends could remain the default and fallback paths. Neon would initially be an opt-in experimental backend, enabled only for the hardware generations and capabilities it supports reliably.

For production use, I suggest defining an explicit adoption gate for each workload:

• Correct results across a defined conformance test set
• No GPU resets, hangs, or kernel faults
• Acceptable memory usage and long-running stability
• Better end-to-end performance than the existing backend

“End-to-end” is important here. The benchmark should include buffer upload, synchronization, command submission, execution, and readback or presentation. A faster shader or command stream alone would not be enough if data transfer and synchronization make the complete workload slower.

This would allow development to progress in small usable steps:

1. Implement one compute workload on one exact AMD RDNA generation.
2. Benchmark it against the Vulkan backend on the same hardware.
3. Use Neon for that workload only when it passes the correctness, stability, and performance gates.
4. Keep Vulkan as the automatic fallback.
5. Expand the supported capability set one milestone at a time.

I would avoid transparent per-command mixing inside one wgpu Device at first, since resources and synchronization belong to a specific backend. A simpler first model would be backend selection per Adapter or Device. If selective compute acceleration is useful later, it could be exposed explicitly through staging copies first, followed by dma-buf and syncobj interoperability when zero-copy sharing is ready.

Neon may still be valuable in a zero-userspace-dependency mode even when performance is only comparable to Vulkan. However, it should not become the default production backend for a workload until it provides a measurable advantage or solves a deployment constraint that the existing backend cannot.

[kolkov]

Great analysis, @TimLai666. This is exactly the kind of structured thinking Neon needs.

Your adoption gate framework maps well to how we're planning it:

What we already agree on:

• Neon is opt-in, post-v1.0. Vulkan/DX12/Metal/GLES/Software ship as production backends in v1.0 (December 2026). Neon is a research track.
• Backend selection per Adapter/Device — not per-command mixing. This is the wgpu-rs model too (wgpu::Backends:: flags at instance creation).
• One compute workload on one AMD RDNA generation first. Phase 1 in ADR-048 is exactly this: DRM foundation + compute MVP on RDNA, validated against Vulkan path.

What your comment adds that we should formalize:

The explicit gate criteria are valuable. We'll adopt them as Neon's promotion checklist:

1. Conformance: pass a defined test set (subset of WebGPU CTS or our own)
2. Stability: no GPU resets, hangs, or kernel faults over N hours
3. Memory: no leaks, bounded VRAM usage
4. Performance: end-to-end improvement (not just command stream speed)

The end-to-end point is particularly important. A faster PM4 submission path means nothing if GEM_CREATE + mmap staging is slower than Vulkan's optimized memory pools. We'll benchmark the full cycle.

On zero-dependency value:

You're right that Neon has value even at comparable performance — embedded Linux without Mesa, CI environments without GPU drivers, minimal container deployments. This is a legitimate adoption path independent of raw speed.

Thanks for the thoughtful contribution.