Skip to content

Enterprise API Audit — Public API Cleanup #218

Description

@kolkov

Enterprise API Audit — wgpu Public API Cleanup

Tracking issue for wgpu public API improvements identified during enterprise audit (Flutter embedding scenario, @lkmavi) and cross-validation (3 research agents).

HAL Leaks in Public API

These force users to import wgpu/hal or wgpu/core — breaking the abstraction that consumers only need root wgpu package.

  • Surface.HAL() returns hal.Surface (surface_native.go:245) — replace with specific methods or unexport
  • Surface.SetPrepareFrame() takes core.PrepareFrameFunc (surface_native.go:182) — define callback type in root package

Missing Public API Methods

HAL implementations exist but public wrappers don't — consumers must drop to device.HalDevice().

  • Device.CreateQuerySet — HAL ready on all 6 backends (Vulkan, DX12, Metal, GLES, Software, Noop)
  • Device.CreateRenderBundleEncoder — HAL partially ready (Vulkan)
  • Device.GetTextureFormatFeatures — per-format capability query (filterable, blendable, MSAA)

Type Cleanup

  • MaxBindGroups = 8 — added MinBindGroups = 4 (v0.30.0)
  • StencilOperation = hal.StencilOperation alias — moved to gputypes.StencilOperation (v0.30.0, BREAKING)

v1.0 Planning: Type Aliases

31 type X = gputypes.X aliases + 46 const re-exports + hal/core aliases in types.go/error.go/descriptor.go. Per Go proposal #18130: type aliases are for gradual code repair during migration, not permanent re-export. go doc shows type TextureFormat = gputypes.TextureFormat — confuses users about canonical import path.

46 const re-exports (BufferUsageVertex = gputypes.BufferUsageVertex etc.) also inflate the API surface. No Go style guide recommends or condemns this pattern — it's a grey area. For enterprise quality: users should import gputypes directly for all shared types and constants, wgpu only for wgpu-specific types (Device, Queue, Buffer, etc.).

Proposal for v1.0: remove all type aliases AND const re-exports. Canonical import path: gputypes for shared types/constants, wgpu only for wgpu-specific resources (Device, Queue, Buffer, etc.). Breaking change — migration guide needed.

@lkmavi — you raised this in the enterprise audit. Do you agree with removing both type aliases and const re-exports for v1.0, or do you see cases where const re-exports should stay?

Thread Safety

Audit of concurrent access patterns:

  • Device.releasedatomic.Bool (v0.30.0)
  • Surface has no synchronization — Configure/GetCurrentTexture/Present must be called from single goroutine. Document this constraint explicitly
  • GLES Linux lacks AdapterContext (tracked separately as FEAT-GLES-003) — no mutex, no LockOSThread on Device/Queue. Windows GLES has proper AdapterContext pattern

Queue, Buffer.Release, DestroyQueue, CommandEncoder — all properly synchronized.

Cross-repo coordination (related to wgpu API decisions)

These live in other repos but are directly affected by wgpu API changes:

  • gogpu Context.SurfaceView() returns *wgpu.TextureView (gogpu/context.go:178) — forces gogpu consumers to import wgpu. Should return gpucontext.TextureView (opaque handle). Blocked until wgpu API is stabilized.
  • gogpu DeviceProvider returns *wgpu.Device (gogpu/device_provider.go:14) — duplicate of gpucontext.DeviceProvider. Should be deprecated. Consumers use provider.Device().(*wgpu.Device) type assertion when HAL access needed.
  • gpucontext.AdapterInfo (2 fields) vs gputypes.AdapterInfo (8 fields) — triple definition (gputypes original, wgpu alias, gpucontext subset). Consumers must convert manually. Unify or document canonical source.
  • gg type-asserts provider.Device().(*wgpu.Device) (gg/accelerator.go:137, gg/gpu/gpu.go:46) — if wgpu removes type aliases or changes Device type, gg breaks. Migration guide must cover gg/ui/Born ML.

References

  • @lkmavi enterprise API audit (Flutter embedding scenario)
  • Internal ADR-018 (opaque handle design)

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions