render target: allow an off-screen pass to keep multisampling

[shadowcodex]

createRenderer(canvas, { antialias: true }) gives a scene 4x MSAA on screen. The moment that same scene renders into a render target, it silently drops to one sample:

// src/runtime/webgpu.ts, inside drawTo
internals.passFormat = TARGET_FORMAT;
internals.passSamples = 1;

That line is not wrong on its own, and it took me a while to see why. The target texture is single-sampled, and a pipeline must match its attachment, so 1 was the only valid value. Raising it alone just fails pipeline validation. The missing piece is the multisampled attachment, not the number.

Why it matters

Adopting any off-screen pass — an HDR buffer before tone mapping, a post-processing chain, bloom — costs all anti-aliasing, on every silhouette edge, with no warning. It reads as "my post-processing made everything jaggy", which is a confusing place to end up when the cause is in the runtime rather than in the effect.

The on-screen path already does the right thing (webgpu.ts, the present branch): it allocates a multisampled colour texture, renders into it, and resolves into the swapchain view. The off-screen path just had no equivalent.

What changed

samples?: number on RenderTargetOptions, defaulting to 1 so nothing changes for existing callers. When it is greater than 1:

• a multisampled colour texture at TARGET_FORMAT is allocated as the pass's colour attachment, resolving into the target texture (storeOp: 'discard', since it has no use after the resolve);
• the depth texture gets the same sampleCount, because a pass requires its attachments to agree;
• internals.passSamples carries the target's count instead of a hard-coded 1.

The target texture itself stays single-sampled and receives the resolve, so sampling it afterwards is unchanged.

Tests

A check added to scripts/gpu/entry.ts, following that file's rule that assertions read pixels back. A diagonal edge is drawn into an off-screen target and magnified, and the distinct values along one scanline are counted:

• at 1 sample the edge is a hard step — two values
• at 4 the resolve leaves partial coverage between them

It reuses the existing gpu-target-read fixture rather than adding another, since that fixture's blue channel already carries the stored value straight out of the target.

Both pass on Chrome/WebGPU. Node suite unchanged at 318 passing, npm run typecheck clean. WebKit did not run locally — playwright-core install webkit was missing in my environment, unrelated to this change.

Notes

samples is a number rather than a 1 | 4 union because supported counts are a device capability. Validating it against the device would be a reasonable addition; I left it out rather than guess at the API you would want.

Independent of the render-target filtering PR — either can land without the other. Both were found while building an HDR pipeline on 0.17.2, and we are carrying them as local patches over the published package meanwhile, so there is no urgency from our side.

---

Over to you

Genuine questions, not politeness:

• Is this applicable at all? If it does not fit where BroMetal is going, say so and close it — no offence taken. We carry it as a local patch over the published package today, so nothing of ours is blocked on it landing.
• Is there a better approach? We arrived at this from the outside, without the context you have on the design. If you would solve it differently — a different API shape, a different layer, or a reason the current behaviour is deliberate — we would rather write your version than have you merge ours.
• Anything you want changed — naming, comment style, test placement, scope — tell us and we will do it.

[vercel]

@shadowcodex is attempting to deploy a commit to the Eric Rowell's projects Team on Vercel.

A member of the Team first needs to authorize it.

[shadowcodex]

Please let me know if this isn't applicable, and if there is an alternative.