wgpu/gogpu: a depth-only render pass is never begun and faults on End

[dvoyni]

Parent

Implement the scene plugin

What happens

A render pass with a depth attachment and no colour attachment kills the
process. Not a validation error, a fault: an access violation inside the driver,
several frames of stack away from anything that names a pass.

github.com/gogpu/wgpu/hal/vulkan/vk.(*Commands).CmdEndRenderPass
github.com/gogpu/wgpu/hal/vulkan.(*RenderPassEncoder).End
github.com/dvoyni/cog/wgpu.(*gfxBackend).EndPass          wgpu/gfxpass.go
github.com/dvoyni/cog/gfx.(*GpuQueue).ReplayPasses        gfx/gpuqueue.go

Why

hal/vulkan.(*CommandEncoder).BeginRenderPass returns a render-pass encoder
without beginning a render pass when the descriptor names no colour
attachments:

if e.active == 0 || len(desc.ColorAttachments) == 0 {
    return rpe
}

RenderPassEncoder.End then calls vkCmdEndRenderPass unconditionally, on a
pass that was never begun. Verified present in the pinned
v0.31.6-0.20260827093430 and still present in v0.34.4, so it is a live
upstream gap rather than a stale pin. A browser's own WebGPU encodes the same
descriptor correctly, so the wasm build of the same demo runs the pass.

cog/wgpu.BeginPass already emits the descriptor correctly — passColour
returns nil and the pass is encoded with an empty ColorAttachments and a depth
attachment only. Everything above the HAL is right.

Two shapes reach it, and only one of them is deliberate

The second is the more serious, because nothing in the tree asked for it:

GpuPassDesc could not tell NoTarget() from a texture target whose view
does not exist yet — both resolve to a zero TextureViewID. And every
TemporaryTarget is unresolved on its first frame, because its allocation is a
bake the backend replays after the pass descriptors were built. So the first
frame of any app that renders into a temporary target with depth already emitted
a depth-only descriptor, and already faulted. It has not been seen before only
because nothing in the tree used a temporary target as a camera's colour target
until now.

What was done

Containment, in cog, because the fix is upstream:

• GpuPassDesc.NoColor says a pass declares no colour attachment at all, set
  from head.Target.kind == targetNone, so a zero Target is no longer
  readable as "depth-only".
• wgpu.BeginPass returns nil when the colour attachment does not resolve, for
  either reason. gfx already skips a pass whose BeginPass returned nil.
• A pass that asked for it deliberately (NoColor) reports
  ErrDepthOnlyPassUnsupported once per run, through the plugin, which has a
  kernel handle where the backend does not. The unresolved-view case is silent:
  it is a frame-one artefact of allocation order and there is nothing for a
  caller to do about it.
• The refusal is gated on depthOnlyPassSupported, a per-platform constant:
  false on !js, true on js. The browser runs the pass.

What is still not fixed

A depth-only pass does not execute on the desktop. Its depth texture is left
untouched, so a later pass that loads that depth with LoadPreserve renders
against undefined depth — the whole pass, not one draw. Until the HAL gap
closes, a depth-only pass may be written but its output may not be depended on
in the same frame. cog/scene/spec.md § Passes carries the rule.

This is the constraint shadow maps will have to negotiate, so this ticket stays
the place that records it.

Acceptance criteria

• GpuPassDesc distinguishes "no colour attachment" from "colour attachment
  not resolved yet"
• Neither shape reaches BeginRenderPass as a depth-only descriptor on the
  native path
• The deliberate case is reported once per run and names the pass
• The browser path still encodes the pass
• No-GPU tests over the pass-shape predicate and the refusal's text
• Upstream: hal/vulkan begins a render pass with no colour attachments

[dvoyni]

Containment landed; the ticket stays open for the upstream fix

cog@320487c — "a pipeline declares no colour target for a depth-only pass, and
wgpu declines the one its hal faults on". Exercised by
cog-examples@0e4faf3 (cmd/scene/cameras).

What now works

• No shape reaches BeginRenderPass as a depth-only descriptor on the native
  path. Both do get skipped, and they are told apart: GpuPassDesc.NoColor
  (gfx/translate.go, set from head.Target.kind == targetNone) says a pass
  declares no colour attachment, so a zero Target is no longer readable as
  "depth-only". wgpu.BeginPass returns nil when the colour attachment does not
  resolve, for either reason; gfx already skips a pass whose BeginPass
  returned nil.
• The deliberate case reports once per run and names the pass.
  ErrDepthOnlyPassUnsupported, held on the backend and taken by the plugin,
  which has the kernel handle the render thread does not. The
  unresolved-view case is silent by design: it is a frame-one artefact of
  allocation order with nothing for a caller to do about it.
• The browser path still encodes the pass, gated on
  depthOnlyPassSupported — false on !js, true on js.

How it was verified

The fault, the fix and the difference between the two platforms were all run,
not reasoned about:

• Before: cmd/scene/cameras on an RTX 4070 SUPER / Vulkan died in
  vkCmdEndRenderPass inside EndPass. Bisected by giving the depth pass a
  colour target, which made the crash go away.
• After: the same demo runs, and the HUD carries reports 1 naming
  scene.camera-200.depth. The first refusal fired against
  scene.camera-300.forward instead — the main camera's own pass, on frame one,
  because its temporary target had no view yet. That misfire is what found the
  second shape, and it is fixed by NoColor.
• Browser: the wasm build through cmd/web/build.sh cameras, driven over
  CDP with a swiftshader WebGPU adapter, reports nothing and renders the pass —
  depth pass packed 1, four scene passes.
• No-GPU tests over the pass-shape predicate and the refusal's text
  (wgpu/gfxdepthonly_test.go), including the case NoColor exists for: a
  texture target whose view is not created yet must not be declined.

What remains, and it is the only thing

• Upstream: gogpu/wgpu's hal/vulkan.(*CommandEncoder).BeginRenderPass
  begins a render pass with no colour attachments, instead of returning an
  encoder that never began one for End to fault on.

Until then a depth-only pass does not execute on the desktop and its depth
texture is left untouched, so its output may not be depended on in the same
frame. The rule is in cog/scene/spec.md § Passes. It blocks nothing today —
cameras is arranged so the skip costs no pixel — and it is the constraint
shadow maps will have to negotiate, which is why this ticket stays open rather
than closing on the containment.

[dvoyni]

The upstream half is now a pull request: gogpu/wgpu#353.

What the fix turned out to be

Two defects, not one. The second was not in the original report and nothing in this tree asked for it.

The pass is never begun. BeginRenderPass derived the render area and the sample count from the colour attachments alone, so it returned before vkCmdBeginRenderPass whenever ColorAttachments was empty. RenderPassCache.createRenderPass and createFramebuffer already handled ColorCount == 0 correctly — a depth-only subpass with PColorAttachments nil is exactly what they build. Only the encoder refused.

End ends a pass that was never begun. It called vkCmdEndRenderPass whenever the command buffer was active. That also fires on the two other early returns in BeginRenderPass — a descriptor whose attachments do not resolve, and a render pass or framebuffer that could not be created — so those were already unsafe, independently of depth-only passes. The fix gates End on whether the begin actually ran, which closes all three.

Two things the report got wrong

It is not Intel-specific. Reproduced on an NVIDIA GeForce RTX 4070 SUPER. vkCmdEndRenderPass without a matching begin is undefined behaviour on any implementation; the surrounding Intel-driver workarounds in that file are unrelated.

Rust wgpu-hal is not the reference here. Its RenderPassDescriptor carries extent and sample_count as caller-supplied fields, so begin_render_pass reads them off the descriptor and never derives them from attachments. gogpu's HAL descriptor carries neither, which is why it has to derive them — and why a depth-only pass has only the depth attachment to derive them from.

Acceptance criteria

• GpuPassDesc distinguishes "no colour attachment" from "colour attachment not resolved yet"
• Neither shape reaches BeginRenderPass as a depth-only descriptor on the native path
• The deliberate case is reported once per run and names the pass
• The browser path still encodes the pass
• No-GPU tests over the pass-shape predicate and the refusal's text
• Upstream: hal/vulkan begins a render pass with no colour attachments — written and verified, awaiting review in fix(vulkan): begin depth-only render passes instead of faulting on End gogpu/wgpu#353

The last box stays unticked until #353 merges, not because the work is outstanding.

State of this tree

All three modules now replace github.com/gogpu/wgpu => ../wgpu, pointing at the fork clone at cog-games/wgpu. A replace only applies from the main module, so cog, cog-examples and feuds-26 each needed their own.

That moved the tree off the v0.31.6 pin to v0.34.x, which was not free: gogpu/gogpu v0.53.0 does not compile against wgpu v0.34, so it went to v0.54.0, carrying gputypes to v0.8.0, naga to v0.19.0 and gpucontext to v0.31.3. Three call sites in cog/wgpu followed that API — Draw/DrawIndexed take gputypes.DrawArgs/DrawIndexedArgs instead of positional uint32s, and VertexBufferLayout moved from wgpu to gputypes.

Green after the bump: cog's 10 packages, the seven scene demos and their acceptance suite, and feuds-26.

depthOnlyPassSupported stays false on the native path. Flipping it while the behaviour comes from a local replace would make it true only on this machine. It flips when #353 merges, a release carries it, and the pin becomes a real version — at which point the replaces come out of all three modules and scene/spec.md § Passes can lose the rule.

Until then the constraint the spec records still holds for anyone else building this tree.

[dvoyni]

Closing. Everything this repo can do is done and committed; the last acceptance criterion is not work that lives here.

In this tree (cog@b81048a, and 320487c before it): a depth-only pass is distinguished from an unresolved target, neither shape reaches the HAL as a depth-only descriptor on the native path, the deliberate case reports once per run, the browser path still encodes the pass, and no-GPU tests cover the predicate and the refusal.

Upstream, the actual HAL fix is written, verified against an NVIDIA RTX 4070 SUPER and open as gogpu/wgpu#353 (dvoyni/wgpu@32c4404). Its last box stays unticked here because merging it is not this repo's call — that is why this closes rather than waiting.

What is left has a home: #117 — pin the released version, drop the replace from all three modules, flip depthOnlyPassSupported, and amend scene/spec.md § Passes. It is triggered by #353 merging, not by anything here.

The constraint this ticket exists to record still holds until then, and is why the spec rule stays: a depth-only pass may be written, but its output may not be depended on in the same frame. #52 has been told, since its default shadow map is built from exactly the pass that does not execute.

[dvoyni]

The last acceptance criterion is now met upstream, so the loop this ticket
opened is shut.

gogpu/wgpu#353 is merged as
0e62880. Both defects the PR carried — the pass never begun because
BeginRenderPass derived the render area and sample count from the colour
attachments alone, and End calling vkCmdEndRenderPass on it regardless — are
in upstream main.

The local tree is out of the build again

All three modules dropped replace github.com/gogpu/wgpu => ../wgpu and take the
module from upstream:

module	commit
cog	65c7b5c
cog-examples	6851400
feuds-26	23413aa

These revert cog@b81048a, cog-examples@fcdd751 and feuds-26@1a9fb7e, the
three "take wgpu from the local tree" pins.

Why a pseudo-version rather than a tag

The pin is v0.34.5-0.20260907183125-0e62880c3b55 — the merge commit itself. No
release tag contains the fix yet: the newest upstream tag is v0.34.4
(90d71ec), which predates the merge. The fix is genuinely in the module that
resolves, not only in the local checkout — the depth-only branch is present at
hal/vulkan/command.go:838-850 in the downloaded version.

Worth a go get github.com/gogpu/wgpu@v0.34.5 once gogpu cuts the tag, to move
off the pseudo-version. That is bookkeeping, not a defect, and it does not need
this ticket to stay open.

go build ./... and go test ./... pass in all three modules.