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.
Missing Public API Methods
HAL implementations exist but public wrappers don't — consumers must drop to device.HalDevice().
Type Cleanup
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:
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)
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/halorwgpu/core— breaking the abstraction that consumers only need rootwgpupackage.Surface.HAL()returnshal.Surface(surface_native.go:245) — replace with specific methods or unexportSurface.SetPrepareFrame()takescore.PrepareFrameFunc(surface_native.go:182) — define callback type in root packageMissing 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— addedMinBindGroups = 4(v0.30.0)StencilOperation = hal.StencilOperationalias — moved togputypes.StencilOperation(v0.30.0, BREAKING)v1.0 Planning: Type Aliases
31
type X = gputypes.Xaliases + 46 const re-exports + hal/core aliases intypes.go/error.go/descriptor.go. Per Go proposal #18130: type aliases are for gradual code repair during migration, not permanent re-export.go docshowstype TextureFormat = gputypes.TextureFormat— confuses users about canonical import path.46 const re-exports (
BufferUsageVertex = gputypes.BufferUsageVertexetc.) also inflate the API surface. No Go style guide recommends or condemns this pattern — it's a grey area. For enterprise quality: users should importgputypesdirectly for all shared types and constants,wgpuonly for wgpu-specific types (Device, Queue, Buffer, etc.).Proposal for v1.0: remove all type aliases AND const re-exports. Canonical import path:
gputypesfor shared types/constants,wgpuonly 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.released→atomic.Bool(v0.30.0)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:
Context.SurfaceView()returns*wgpu.TextureView(gogpu/context.go:178) — forces gogpu consumers to importwgpu. Should returngpucontext.TextureView(opaque handle). Blocked until wgpu API is stabilized.DeviceProviderreturns*wgpu.Device(gogpu/device_provider.go:14) — duplicate ofgpucontext.DeviceProvider. Should be deprecated. Consumers useprovider.Device().(*wgpu.Device)type assertion when HAL access needed.gpucontext.AdapterInfo(2 fields) vsgputypes.AdapterInfo(8 fields) — triple definition (gputypes original, wgpu alias, gpucontext subset). Consumers must convert manually. Unify or document canonical source.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