`importExternalTexture` silently fails on Linux with Mesa open-source drivers (RADV/NVK), causing render loop crash and GPU device loss

[kfxs]

According to analysis done with Claude (claude.ai):

Environment

OS	Ubuntu 24.04, Linux 6.8.0-100-generic
Browser	Chrome 138.0.7204.183
Chrome flags	--enable-unsafe-webgpu (required, WebGPU is blocklisted by default on Linux)
GPU (integrated)	AMD Radeon Graphics - RADV RENOIR, Mesa 25.0.7
GPU (discrete)	NVIDIA GeForce RTX 3050 Laptop GPU - NVK GA107 (Mesa open-source Vulkan)
WebGPU backend	Vulkan via Dawn
Driver type	Open-source Mesa (RADV for AMD, NVK for NVIDIA - NOT proprietary NVIDIA)

Note: WebGPU must be enabled via --enable-unsafe-webgpu
because Chrome 138 on Linux has WebGPU
blocklisted by default (chrome://gpu -> "WebGPU has
been disabled via blocklist").
Vulkan itself works (chrome://gpu -> Vulkan: Enabled).

Bug Description

device.importExternalTexture({ source: htmlVideoElement
}) fails silently on Linux with Mesa
open-source drivers. The call does NOT throw a
JavaScript exception and does NOT return null
-- it returns a GPUExternalTexture object that is
internally marked as invalid by Dawn's
validation layer. This invalid object is
indistinguishable from a valid one in JavaScript.

The root cause appears to be a memory allocation
mismatch inside Dawn's ImportMemory:

  Requested allocation size (8912912) is smaller than

the image requires (9830400).
at ImportMemory

This repeats every render frame (60fps), flooding the
console with hundreds of errors per second.

Error Chain

The silent failure cascades through the entire render
pipeline:

1. importExternalTexture({ source: video }) -> returns
   an invalid GPUExternalTexture (no exception thrown)
2. Invalid texture is passed to the compositor's bind
   group
3. [Invalid Texture].CreateView() -> [Invalid
   TextureView]
4. BeginRenderPass with invalid TextureView as
   colorAttachments[0] -> [Invalid CommandBuffer]
5. Queue.Submit([Invalid CommandBuffer]) -> no-op,
   nothing renders
6. Render loop stalls indefinitely (RenderLoop: Render
   stall detected: Xms since last render)
7. Eventually: Device lost -- A valid external Instance
   reference no longer exists.
8. Recovery attempt: requestAdapter() now returns null
   -> engine fails to recover
9. App is stuck on "Initializing WebGPU..." screen
   permanently

Full Console Output

Requested allocation size (8912912) is smaller than the
image requires (9830400).
at ImportMemory ()
[... repeats ~100+ times per second ...]

[Invalid Texture] is invalid.

• While calling [Invalid
  Texture].CreateView([TextureViewDescriptor]).
  [... repeats ...]

[Invalid TextureView] is invalid.

• While validating colorAttachments[0].
• While encoding [CommandEncoder
  (unlabeled)].BeginRenderPass([null]).
• While finishing [CommandEncoder (unlabeled)].
  [... repeats ...]

[Invalid CommandBuffer] is invalid.

• While calling [Queue].Submit([[Invalid
  CommandBuffer]])
  [... repeats ...]

WebGPU: too many warnings, no more warnings will be
reported to the console for this GPUDevice.

[RenderLoop] Warning: Render stall detected: 4131ms
since last render (idle=false, playing=false)
[RenderLoop] Warning: Render stall detected: 6131ms
since last render (idle=false, playing=false)
[... continues growing indefinitely ...]

[WebGPUContext] Error: Device lost A valid external
Instance reference no longer exists.
[WebGPUContext] WebGPU is experimental on this
platform.
[WebGPUContext] Failed to create WebGPU Context
Provider
[WebGPUContext] Error: Failed to get GPU adapter

Additional Notes

• chrome://gpu confirms Vulkan is enabled and Dawn sees
  all three GPU adapters (AMD RADV,
  NVIDIA NVK, llvmpipe) as WebGPU: Available. The
  blocklist only affects the browser-level
  exposure, not Dawn itself.

• The NVIDIA adapter is using NVK (Mesa's open-source
  Nouveau Vulkan), not the proprietary
  NVIDIA driver. The issue likely affects both RADV and
  NVK.

• This issue does NOT occur with the proprietary NVIDIA
  driver (nvidia-driver package), which
  is a separate installation from the Mesa open-source
  stack.

• WebCodecs VideoFrame as the importExternalTexture
  source may have the same issue (untested).