Fix for gh issue: 21031, use proper size for WGPUTextureFormat

[warvstar]

Fix for #21031

• Use proper size for WGPUTextureFormat U64 -> U32

[sbc100]

Thanks!

@kainino0x would it be hard to add tests for this?

[sbc100]

Perhaps a comment along the lines of // viewFormatsPtr pointer to an array of TextureFormat which is an enum of size uint32_t

[kainino0x]

Nice find, thank you! Glad to find that these bindings work in wasm64 at all :)

We have the same problem in

emscripten/src/library_webgpu.js

Line 2501 in 4765f9c

desc["requiredFeatures"] = Array.from({{{ makeHEAPView(`${POINTER_BITS}`, 'requiredFeaturesPtr', `requiredFeaturesPtr + requiredFeaturesCount * ${POINTER_SIZE}`) }}},

which takes WGPUFeatureName which is 32-bit.

[kainino0x]

re: testing, I think we could patch a test into this existing test:

emscripten/test/webgpu_basic_rendering.cpp

Line 308 in 4765f9c

wgpu::TextureDescriptor descriptor{};

         wgpu::TextureDescriptor descriptor{};
         descriptor.usage = wgpu::TextureUsage::RenderAttachment | wgpu::TextureUsage::CopySrc;
         descriptor.size = {1, 1, 1};
         descriptor.format = wgpu::TextureFormat::BGRA8Unorm;
+        // Test for viewFormats binding
+        std::array<wgpu::TextureFormat, 2> viewFormats =
+            { wgpu::TextureFormat::BGRA8Unorm, wgpu::TextureFormat::BGRA8Unorm };
+        descriptor.viewFormatCount = viewFormats.size();
+        descriptor.viewFormats = viewFormats.data();
         readbackTexture = device.CreateTexture(&descriptor);

or something like that. The resulting JS call will be:

// before bugfix, throws TypeError:
d.createTexture({ size: [4, 4], usage: GPUTextureUsage.COPY_SRC, format: 'bgra8unorm',
    viewFormats: [undefined, undefined /* or possibly something else due to buffer overrun */] });
// after bugfix, OK:
d.createTexture({ size: [4, 4], usage: GPUTextureUsage.COPY_SRC, format: 'bgra8unorm',
    viewFormats: ['bgra8unorm', 'bgra8unorm'] });

Unfortunately it wouldn't be quite so easy to test the requiredFeatures one.

[kainino0x]

I've addressed the remaining work in #21078