Support for texture-formats-tier1 and texture-formats-tier2

[fanciful-marmot]

I'm very interested in using this tool for recording/playback to help with bug reports and investigations but I noticed that tier1 and tier2 texture-formats aren't supported (here).

Simply adding these features to the list gives a very cryptic error when attempting playback of the recording. What's involved in adding support for this? Depending on complexity I can help with this but some guidance would be great

[Chainsawkitten]

Adding these should be pretty simple, but there is a slight complication due to lack of support in wgpu.

In general, adding support for a new feature involves:

Adding it to the allowlist

This is the __WebGPUReconstruct_supportedFeatures you linked to. During capture, we will pretend any feature not in the allowlist is not supported by the adapter and will remove it from the requested features when requesting the device. This is to ensure we can actually properly capture/replay everything.

Upgrade WebGPU implementations if necessary

For the texture-formats-tier1 and texture-formats-tier2 case:

• The Dawn version currently used (7439) already supports both in DirectX 12 and Vulkan backends, so no action necessary.
• The wgpu-native version used (25.0.2.2) doesn't support either feature, but there's no version we can upgrade to that does, so no action necessary. (wgpu does have a native-only feature for 16-bit unorm/snorm formats from texture-formats-tier1, but it doesn't add the capability guarantees from texture-formats-tier1 so afaik we can't map to that.)

Lack of wgpu support means replay of captures using the feature will only work in the Dawn version of the replayer, unless we wait for wgpu-native support before adding it. We already support some exclusive features like this (eg. subgroups is only supported in the Dawn replayer), so this is fine.

Enable the feature on the device during replay

This is simply adding the feature to the list of desired features. We always ask for all supported features (that we know how to use), regardless of what features were requested during capture. (The replayer always uses a single device and user can ask for a specific backend so this is a part that doesn't match the capture).

Capture/replay any new entry points the feature adds

This is unique per feature. A feature that doesn't add any new API entry points (eg. primitive-index only adds shader features) doesn't need any changes. But if the feature adds any new functions, properties or enum values, these need to be added and handled correctly.

For the texture-formats-tier1 and texture-formats-tier2 case: these mostly just add more capabilities to existing texture formats, which doesn't require any changes. But texture-formats-tier1 also adds a few new texture formats: r16unorm, r16snorm, rg16unorm, rg16snorm, rgba16unorm, rgba16snorm. These need to be added and handled. New texture formats have to be added to:

• GPUTextureFormat
• __WebGPUReconstruct_get_block_size (But all the new formats are uncompressed, so block size is 1x1, which is the default case.)
• __WebGPUReconstruct_get_bytes_per_block

Adding these to GPUTextureFormat will cause some issues due to wgpu. It's not just that wgpu doesn't support the feature; it doesn't define the entry points at all. So adding eg. ["r16unorm", "WGPUTextureFormat_R16Unorm"] to GPUTextureFormat will lead to a compilation error for the wgpu replayer since WGPUTextureFormat_R16Unorm doesn't exist. The proper solution would be for wgpu-native to update its headers. But if we don't want to wait for that, we can work around it. Differences between Dawn and wgpu are handled in replay/WebGPU.hpp. Here we can add:
#define WGPUTextureFormat_R16Unorm WGPUTextureFormat_Force32
etc. If a user tries to replay a capture using one of these formats with the wgpu replayer, they should get some validation error about an invalid texture format. (It would be even nicer to inform the user that the capture uses a feature that isn't supported on the replay device, but that's TBD.)

When any new entry point is added, or an existing entry point is changed in a breaking way, this changes the file format (which is a binary format). So bump the file format version to avoid compatibility issues when attempting to replay a capture file taken with a different version.

Documentation

Update the unsupported features list.

Testing

Either find some existing content online that uses the feature or write some simple test case myself. I'm honestly not particularly thorough, so I wouldn't test every combination of capability and format or anything like that. But it would be nice to at least test:

• Using one existing format with a new capability added by the feature
• Using one of the added formats

---

This may look like an overwhelming list of things to do, but most of these are literally a one line change (I'd estimate a total 30 LOC, maximum). The only thing that usually takes any significant amount of time for me when adding new features is the testing, since I usually end up having to write some test content myself. But it sounds like you already have some content using these features.