1830762 - `GPUTexture` missing `readonly attribute`s

Status: RESOLVED FIXED

(Core :: Graphics: WebGPU, defect)

Description

[Erich Gubler [:ErichDonGubler]]

If you navigate to https://webgpufundamentals.org/webgpu/lessons/webgpu-perspective-projection.html, multiple errors of the following form can be observed:

GPUDevice.createTexture: Element of sequence<unsigned long> branch of (sequence<unsigned long> or GPUExtent3DDict) is not a finite value, so is out of range for unsigned long.

It turns out that our implementation of WebGPU doesn't populate the readonly attributes specified to be on GPUTexture at all! We should, according to section 6.1 ("GPUTexture") of the current WebGPU v1 spec. draft (link).

Comment 1

[Erich Gubler [:ErichDonGubler]]

Attachment: Bug 1830762: refactor(webgpu): move `ConvertExtent{,3DToFFI}` to new `Utility` module r=#webgpu-reviewers

Comment 2

[Erich Gubler [:ErichDonGubler]]

Attachment: Bug 1830762: refactor(webgpu): add `Owning*` variant for `ConvertExtent{,3DtoFFI}` r=#webgpu-reviewers

Depends on D176847

Comment 3

[Erich Gubler [:ErichDonGubler]]

Attachment: Bug 1830762: populate standard attributes for `GPUTexture` r=#webgpu-reviewers

Depends on D176848

Comment 4

[Erich Gubler [:ErichDonGubler]]

This bug breaks things when visiting https://thimbleberry.dev/. The GPUTexture.format attribute of the returned texture isn't being populated, i.e.:

Uncaught (in promise) TypeError: GPUDevice.createRenderPipeline: Missing required 'format' member of GPUColorTargetState.
    createMosaicPipeline MosaicPipeline.ts:86
    memoMemo MemoMemo.ts:44
    memoizeWithDevice CacheKeyWithDevice.ts:33
    get pipeline MosaicShader.ts:101

Comment 5

[Jim Blandy :jimb]

Just to fill in some details:

Those error messages are from GPUDevice.create... methods, but that's because the caller is passing a descriptor whose fields are initialized with values taken from some other texture. For example, webgpufundamentals.org is saying:

      // Get the current texture from the canvas context and
      // set it as the texture to render to.
      const canvasTexture = context.getCurrentTexture();
      renderPassDescriptor.colorAttachments[0].view = canvasTexture.createView();

      // If we don't have a depth texture OR if its size is different
      // from the canvasTexture when make a new depth texture
      if (!depthTexture ||
          depthTexture.width !== canvasTexture.width ||
          depthTexture.height !== canvasTexture.height) {
        if (depthTexture) {
          depthTexture.destroy();
        }
        depthTexture = device.createTexture({
          size: [canvasTexture.width, canvasTexture.height],
          format: 'depth24plus',
          usage: GPUTextureUsage.RENDER_ATTACHMENT,
        });
      }

Because canvasTexture.width / height / etc. are all undefined, the argument to device.createTexture is bogus. The error messages are the DOM bindings complaining when they try to build a C++ mozilla::dom::GPUTextureDescriptor from the JS object.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5e19f3cbd315
refactor(webgpu): move `ConvertExtent{,3DToFFI}` to new `Utility` module r=webgpu-reviewers,jimb
https://hg.mozilla.org/integration/autoland/rev/e7fd9323eaad
refactor(webgpu): add `Owning*` variant for `ConvertExtent{,3DtoFFI}` r=webgpu-reviewers,jimb
https://hg.mozilla.org/integration/autoland/rev/7688e7d3bd4e
populate standard attributes for `GPUTexture` r=webgpu-reviewers,webidl,saschanaz,jimb,jgilbert

Comment 7

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/5e19f3cbd315
https://hg.mozilla.org/mozilla-central/rev/e7fd9323eaad
https://hg.mozilla.org/mozilla-central/rev/7688e7d3bd4e