Allow using a (float32-filterable 2d single level) texture view for an externalTexture binding. about gpuweb HOT 5 OPEN

Firefox has had some long-term hopes of actually never producing RGBA data from video decoders, software or otherwise, and producing only NV12-ish formats, which would allow us to simplify our external texture support. If the WebGPU specification were to allow content to pass ordinary GPUTextures to shaders operating on texture_externals, then we would have to support RGBA external textures in perpetuity.

So it depends on how excited people are about binding non-external texture views to texture_external variables:

• If people are really excited, then it's a valuable feature to the audience, and we should spec it as yet another helpful thing.

• If it's just a "nice to have, and it's free" feature, then we should not provide it, as it does prevent simplifications we were hoping to pursue at some point in the future.

("Is this a cute bracelet, or an annoying handcuff?")

from gpuweb.

I'm surprised that Firefox would want to make video frames always NV12 (even though for most hardware or actual video thing it is much preferred) because it is supportive of WebCodecs and the VideoFrame constructor can take things that are RGB(A) data.

This is more than a pure nice to have feature because we have some folks working on video processing pipelines that introduced a copyExternalImageToTexture to convert a VideoFrame to a GPUTexture because it was more architecturally tractable to have texture_2d<f32> everywhere instead of dynamically generating that or a texture_external. So now they have a 1-copy path instead of a 0-copy. If they could use texture_external everywhere by feeding a GPUTexture in the binding, they would easily get to 0-copy.

from gpuweb.

from gpuweb.

Sure! Ok I didn't realize that videocodec accepted those, so that forces us to handle it, so we're ok with this I think.

from gpuweb.

from gpuweb.