search

webgpu-native / webgpu-headers

https://webgpu-native.github.io/webgpu-headers/
BSD 3-Clause "New" or "Revised" License
361 stars 43 forks source link

Make WGPUImageCopyTexture non-extensible #224

Open kainino0x opened 1 year ago

kainino0x commented 1 year ago

WGPUImageCopyTexture is used in multiple entry points, so it's hard to know if there will ever be extension structs to it that are used across all entrypoints. It would be kind of weird to have extensions that are only allowed in some entrypoints (though now that I think about it, not as weird as I thought). And it doesn't provide extensibility for those entrypoints for anything that doesn't belong in this struct.

Additionally ~I think it's the only struct used in any encoder command which is extensible~. It seems nice to be consistent and not have extensibility for encoder commands. We can always introduce alternate versions of encoder commands.

I'll note that copyExternalImageToTexture (which we don't have in this header yet because it takes a dependency on some other library for representing JS values in C) does "extend" this struct in the JS API with GPUImageCopyTextureTagged. However if we do get that in this API I think it should be (1) a separate struct, not a chained struct, and (2) extensible (since it's not an encoder command, and it's a complicated operation with color conversions and stuff).

Spin-off of #216.

kainino0x commented 1 year ago

In today's meeting we agreed to do this, although I hadn't articulated all of the stuff above yet so it's somewhat tentative.

Kangz commented 5 months ago

What about WGPUImageCopyBuffer? I assume it shouldn't be chained either. However WGPUTextureDataLayout being chainable seems important?

kainino0x commented 5 months ago

Oops, I totally missed those ("I think it's the only struct used in any encoder command which is extensible").

Added to agenda. If we want to make encoder commands use non-extensible structs then WGPUTextureDataLayout shouldn't be extensible either. @Kangz any particular way you think it might be extended?

Tangentially, filed #286 about the name of WGPUTextureDataLayout vs upstream GPUImageDataLayout.

Kangz commented 5 months ago

Apart from optional padding between texel, but that seems somewhat unlikely, I don't see any reason to extend WGPUTextureDataLayout. Vulkan only has VkCopyCommandTransformInfoQCOM and a potential way to swizzle in host<->image copies. IMHO we can add these later if need be with additional methods called Foo2 that take extensible structs.

kainino0x commented 5 months ago

Apr 11 meeting: