RFC: Common Backend Abstraction for Third-Party Extensibility

[kolkov]

Context

Currently, gogpu and gg have separate backend systems. While this works internally, it creates a barrier for third-party backend developers.

The Extensibility Problem

Imagine a user wants to create:

• WebGL backend for browser (via wasm)
• DirectX 11 backend for legacy Windows
• Custom software renderer optimized for their use case
• Backend for embedded/specialized GPU

Current situation:

• They need to understand TWO different registration systems
• Implement TWO different interfaces
• Handle TWO sets of build tags
• No guarantee of consistency

With a common library:

• ONE interface to implement
• ONE registration mechanism
• Works automatically with gogpu, gg, and future ui

Proposal: gogpu/gpubackend

// gogpu/gpubackend - common backend infrastructure

// BackendType identifies the backend
type BackendType int

const (
    BackendAuto BackendType = iota
    BackendNative  // Pure Go (gogpu/wgpu)
    BackendRust    // wgpu-native FFI
    BackendCustom  // Third-party backends start here
)

// BackendInfo describes a backend
type BackendInfo struct {
    Name        string
    Type        BackendType
    Priority    int           // For auto-selection
    Platforms   []Platform    // Supported platforms
    GPURequired bool
}

// Registry for backend registration
type Registry struct { ... }

func (r *Registry) Register(info BackendInfo, factory Factory)
func (r *Registry) Get(name string) Backend
func (r *Registry) Default() Backend
func (r *Registry) List() []BackendInfo

Third-Party Usage Example

// In user's custom backend package
package mybackend

import "github.com/gogpu/gpubackend"

func init() {
    gpubackend.Register(gpubackend.BackendInfo{
        Name:      "webgl",
        Type:      gpubackend.BackendCustom,
        Priority:  50,  // Lower than native (100)
        Platforms: []gpubackend.Platform{gpubackend.PlatformWasm},
    }, NewWebGLBackend)
}

Then users can:

// Use in gogpu
app := gogpu.NewApp(config.WithBackend("webgl"))

// Use in gg
dc := gg.NewContext(800, 600, gg.WithBackend("webgl"))

Architecture with ui

                    User Application
                           |
         +-----------------+-----------------+
         |                 |                 |
      gogpu               gg                ui
     (3D/GPU)           (2D)              (GUI)
         |                 |                 |
         +-----------------+-----------------+
                           |
                   gogpu/gpubackend
                      (registry)
                           |
         +---------+-------+-------+-----------+
         |         |               |           |
      Native     Rust          Software   Third-Party
      (wgpu)   (wgpu-n)        (CPU 2D)   (WebGL, etc)

Questions

1. Is third-party extensibility a priority? Do we expect users to write custom backends?

2. What should the common interface look like?

   • Full WebGPU (120+ methods) - complex but complete
   • Minimal subset - easier to implement
   • Layered (required + optional) - best of both?

3. How does ui fit in?

   • Option A: ui is backend-agnostic (uses gogpu + gg high-level APIs)
   • Option B: ui can prefer specific backends for features (e.g., text rendering)

4. Build tags convention?

   • //go:build !nobackend_webgl - opt-out
   • //go:build backend_webgl - opt-in
   • Something else?

Looking for Feedback

• Would you use this to create a custom backend?
• What backends would you want to see?
• Any concerns about the approach?

[kolkov]

Related: UI Extensibility

The same extensibility principles should apply to gogpu/ui when we design it:

Widget System

// Users should be able to create custom widgets
type Widget interface {
    Layout(constraints Constraints) Size
    Paint(dc *gg.Context)
    HandleEvent(event Event) bool
}

// Register custom widgets
ui.RegisterWidget("my-chart", NewChartWidget)

Theme System

// Pluggable themes
type Theme interface {
    Colors() ColorPalette
    Typography() Typography
    Spacing() Spacing
    PaintButton(dc *gg.Context, state ButtonState)
    PaintInput(dc *gg.Context, state InputState)
    // ...
}

// Users can create and register custom themes
ui.RegisterTheme("corporate", NewCorporateTheme)
ui.SetTheme("corporate")

Layout Engines

// Custom layout algorithms
type LayoutEngine interface {
    Layout(children []Widget, constraints Constraints) []Rect
}

// Built-in: Flexbox, Grid, Stack
// User can add: Masonry, Constraint-based, etc.
ui.RegisterLayout("masonry", NewMasonryLayout)

Potential Architecture

gogpu/ui
    |
    +-- widgets/          # Built-in widgets (Button, Input, List...)
    +-- themes/           # Built-in themes (Light, Dark, System)
    +-- layouts/          # Built-in layouts (Flex, Grid, Stack)
    +-- registry.go       # Widget/Theme/Layout registration
    |
    v
User code can:
    - Implement Widget interface -> custom components
    - Implement Theme interface -> custom styling
    - Implement LayoutEngine -> custom layouts

This ties back to the backend question: if we have a unified gogpu/gpubackend, then UI themes could potentially optimize for specific backends (e.g., GPU-accelerated blur effects only on capable backends).

Thoughts?

[kolkov]

✅ RFC Implemented: gpucontext v0.2.0 → v0.3.0

This RFC has been implemented as gogpu/gpucontext — a shared infrastructure package for the gogpu ecosystem.

What was delivered

RFC Request	Implementation
Common registry	Registry[T] — generic, thread-safe, priority-based
Backend interface	DeviceProvider — Device, Queue, Adapter, SurfaceFormat
Event system	EventSource — keyboard, mouse, window, IME
Third-party extensibility	Register(), Get(), Best(), Available()

Released versions

• gpucontext v0.1.1 — DeviceProvider, EventSource, Registry
• gpucontext v0.2.0 — Added IME support for CJK input
• gpucontext v0.3.0 — (planned) Texture, TextureCreator, RenderTarget interfaces
• gg v0.21.0 — Uses gpucontext for device integration

---

Architecture Decision: gputypes + gpucontext (2026-01-28)

Final Architecture

Package	Role	Dependencies
gputypes	All WebGPU types (TextureFormat, BufferUsage, etc.)	ZERO
gpucontext	Integration interfaces (DeviceProvider, Texture, etc.)	imports gputypes

                    gputypes (ZERO deps)
                           │
         ┌─────────────────┼─────────────────┐
         │                 │                 │
         ▼                 ▼                 ▼
    gpucontext          wgpu          go-webgpu/webgpu
  (imports gputypes)  (imports)         (imports)
         │                 │                 │
         └────────┬────────┴────────┬────────┘
                  ▼                 ▼
               gogpu             born-ml

Why Two Packages?

Aspect	gputypes	gpucontext
Responsibility	Data definitions	Behavioral contracts
Change frequency	Rare (WebGPU spec)	Medium (API evolution)
Size	Large (100+ types)	Small (10-15 interfaces)

Principle: Separation of data types from behavioral interfaces.

Why gpucontext imports gputypes?

Interfaces need types in method signatures:

type DeviceProvider interface {
    SurfaceFormat() gputypes.TextureFormat  // ← uses gputypes
}

Without import: Each project defines incompatible types → type conversion everywhere.
With import: Types are compatible across entire ecosystem → seamless integration.

New Interfaces in gpucontext v0.3.0

For gg ↔ gogpu integration:

• Texture — GPU texture resource
• TextureCreator — Creates textures
• RenderTarget — Draws textures
• RenderContext — Combines TextureCreator + RenderTarget

Full rationale: GPUCONTEXT_GPUTYPES_DECISION.md

---

Closing this RFC as implemented. Future enhancements tracked in respective repos.