public readonly record struct WebGpuCommandOne recorded command, as flat as it can be made.
No guide page documents this yet — the page shows what the code says about itself.
Remarks
Why a deferred stream at all, when WebGPU has command encoders? Because an encoder belongs to one thread and there is only one thread in a browser tab, and the RHI promises that lists record on any thread — one per thread per frame. So a list records into managed memory and the queue replays it at submit, which is exactly what the GL backend does and for exactly the same reason (docs/plan/05).
It buys two other things. The replay is shared between the native and browser surfaces, so neither writes it. And the stream is a flat array of blittable values with its variable-length parts in side buffers — so a browser surface that later wants to hand the whole frame across the interop boundary in one call has something to hand across.
Fields are named by position rather than by meaning because the meaning differs per kind; WebGpuCommandList is the only writer and WebGpuQueue the only reader, and each command's layout is stated where it is recorded.
Fields and properties (10)
public WebGpuCommandKind KindWhich command it is.
public int AThe first small integer operand.
public int BThe second.
public int CThe third.
public int DThe fourth.
public long EThe first wide operand — an offset or a size in bytes.
public long FThe second.
public long GThe third.
public WebGpuObject Object0The first WebGPU object it names.
public WebGpuObject Object1The second.
Methods (1)
public WebGpuCommand(WebGpuCommandKind Kind, int A = 0, int B = 0, int C = 0, int D = 0, long E = 0, long F = 0, long G = 0, WebGpuObject Object0 = default(WebGpuObject), WebGpuObject Object1 = default(WebGpuObject))One recorded command, as flat as it can be made.
Used by (2)
- WebGpuCommandListVixen.Graphics.WebGPU
- WebGpuDeviceVixen.Graphics.WebGPU