WebGPU: Deno Panics when a destroyed texture is used in a render pass

[matthew-wong1]

Hi!

The following WebGPU program panics when a destroyed texture is used in a render pass. I think the correct behaviour is to throw some sort of validation error instead.

I've tested this on v1.46.3 and 2.0.0-rc.5, and both versions produce the same error. I've only tested this on macOS.

Here is the WebGPU program:

const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();
const encoder = device.createCommandEncoder();
const texture = device.createTexture({
  dimension: "2d",
  format: "rg16float",
  size: {
    width: 1540,
  },
  usage: GPUTextureUsage.RENDER_ATTACHMENT,
});

const textureView = texture.createView();
const renderPassEncoder = encoder.beginRenderPass({
  colorAttachments: [
    {
      r: 1.0,
      loadOp: "load",
      storeOp: "store",
      view: textureView,
    },
  ],
});
texture.destroy();

renderPassEncoder.end();

This is how I ran the program:

RUST_BACKTRACE=1 DENO_WEBGPU_BACKEND=metal deno run --allow-read --unstable-webgpu --allow-write webgpu.js

And here is the backtrace:

thread 'main' panicked at /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-core-0.21.1/src/storage.rs:113:39:
TextureView[Id(0,1,mtl)] does not exist
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: wgpu_core::storage::Storage<T>::get
   3: wgpu_core::track::stateless::StatelessTracker<T>::add_single
   4: wgpu_core::command::render::<impl wgpu_core::global::Global>::command_encoder_run_render_pass_impl
   5: wgpu_core::command::render::<impl wgpu_core::global::Global>::command_encoder_run_render_pass
   6: deno_webgpu::render_pass::op_webgpu_render_pass_end::op_webgpu_render_pass_end::v8_fn_ptr
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[matthew-wong1]

The same panic (same line) also occurs if you create a query set and then destroy it (in a similar manner to the texture view above).

[crowlKats]

This might be fixed in recent wgpu (the rust crate) releases. After 2.0 I will take a look into doing an update of the crates and will see if this is then fixed. else if this is still present upstream, i'll see to it that this gets fixed