To start with we'll just do a simple path requiring a CPU readback. Direct import of GPU memory will follow in later bugs for each platform

Upcoming patches implementing WebGPU external textures will perform
work on the parent side and require the ability to raise errors, but
we wish to keep the implementation in a separate file.

In order to support webgpu's GPUExternalTexture we must first be able
to import video frames into wgpu. To do so we introduce the concept of
an external texture "source". This consists of between 1 and 3
textures and texture views, in order to support single-plane RGBA or
multiplanar YCbCr data. The source is implemented as a distinct
concept from the external texture itself so that multiple external
textures can be created from the same source.

An external texture source has both a client-side and host-side
representation. The client side is responsible for managing the
lifecycle of the host side. It obtains a SurfaceDescriptor from the
current layers::Image of the video element or frame it was imported
from, and sends this to the host side. The host side is responsible
for creating the wgpu Textures and TextureViews it needs from the
SurfaceDescriptor. It also holds various pieces of information derived
from the imported frames that will be required to construct the
wgpu::ExternalTextureDescriptor required to create a
wgpu::ExternalTexture.

For now, we always call Image::BuildSurfaceDescriptorBuffer to obtain
the surface descriptor, and therefore only have to handle
SurfaceDescriptorBuffers. In subsequent patches we will handle
GPUVideo surface descriptors to directly import hardware decoded video
frames without requiring a readback.

First we create an ExternalTextureSource using the infrastructure added
in the previous patch, and from that we create an ExternalTexture.

In order to create the external texture the client side passes an
ExternalTextureDescriptor to the host side, which encodes the
source as a optional ID. On the host side additional information is
queried from the ExternalTextureSourceHost, which is combined with the
ExternalTextureDescriptor provided by the client in order to call
wgpu's create_external_texture().

If there was an error importing the source on the client side the
source ID will be None. If there was an error importing the source
on the host side, it will return an empty slice of texture views as its
planes. In either case this indicates we should propagate the error
state to the external texture, and raise an error.

Subsequent patches will allow for creating multiple external textures
from the same source, and returning previously imported external
textures rather than always creating a new one.

Note that for now we have not requested Features::EXTERNAL_TEXTURE when
creating the wgpu device, meaning that any attempts to actually create
an external texture will result in an error.

Backed out for causing bustages on Utility.cpp

Backout link: https://hg-edge.mozilla.org/integration/autoland/rev/5ac8fbc6fa029f72e8b69149018409c299ab8750
Log link: https://treeherder.mozilla.org/logviewer?job_id=521740746&repo=autoland&lineNumber=59663

The above comment reverts 8c6211446542 and 02e5b2a7d70d for causing build bustages on ExternalTexture.h

Push with failures

Failure log

Backout link

https://hg.mozilla.org/mozilla-central/rev/cf2943331ac8
https://hg.mozilla.org/mozilla-central/rev/dc0053f7a5ee
https://hg.mozilla.org/mozilla-central/rev/dea8a0636230

FF143 MDN work for this can be tracked in https://github.com/mdn/content/issues/40774

This appears to add support for GPUExternalTexture and GPUDevice.importExternalTexture().

1. Is that correct? Nothing else?
2. The compatibility data for FF141 indicates that these were supported in FF141 (not 143) and that it was partial support on Windows only (Currently supported on Windows only, in all contexts except for service workers.).
   • That appears to conflict - what is the story?
   • i.e. were these implemented in FF141 and is the support on all OS now, not just Windows?

This bug itself added an implementation of GPUDevice.importExternalTexture(), but behind a pref. That pref was actually enabled for windows in bug 1983594 which landed in Firefox 144. I suspect we mistakenly wrote 141 because the rest of WebGPU was supported in that version, but not external textures.

So these items should say 144 (with the existing "currently supported on windows only.." note.)

(We also now support this on Mac, but not yet linux. But WebGPU is not supported generally on release builds on those platforms yet)