Add new limits added for Compatibility Mode

[kainino0x]

I don't expect these will be removed when we drop compatibility mode, so they should be in core (not a Compat extension struct). Currently:

• maxStorageTexturesInFragmentStage
• maxStorageBuffersInFragmentStage
• maxStorageTexturesInVertexStage
• maxStorageBuffersInVertexStage

[kainino0x]

Dec 19 meeting:

• KN: We should probably take a bet on these and just add them, even though not standardized yet. I think it's very unlikely they'll change.
• CF: Seems fine.
• CF: Think wgpu lies about this. If we see a limit of 0 we just disable writable storage but still allow you to do read-only storage.
  https://github.com/gfx-rs/wgpu/blob/53f40794f275329a48efc7d1c637c91b8e51327d/wgpu-hal/src/gles/adapter.rs#L353-L363

[kainino0x]

I went to implement this and then I made this note:

Note these limits will be part of the core JS spec, because they can't be safely removed from JS (even when compat doesn't exist and they won't do anything).

The reason for this is that if we remove them from GPUSupportedLimits then applications accessing GPUSupportedLimits.maxStorageBuffersInVertexStage will get undefined.

In C, it would be somewhat safer to remove them, but not entirely. The equivalent of adapter.limits is wgpuAdapterGetLimits which takes WGPULimits as an out-struct. If we chained WGPULimits -> WGPUCompatibilityModeLimits which has an SType in the Compat block (0x0002), then non-compat-supporting webgpu.h implementations would skip over¹ the extension struct and leave it uninitialized, instead of initializing it to the correct values, which could impact application behavior.
/note

HOWEVER! An application that doesn't target Compat also won't care about these limits. I was thinking it was good to get these into the main struct just to avoid more extensions. But this is kinda similar to MaxDrawCount, where it's core, but just something most people won't care about, so I think these should be in a block-0x0000 extension instead. Which makes them non-blocking for 1.0.

Footnotes

1. this is the proposed behavior for block 0x0002 to make compat removable from webgpu.h implementations. See Allocation of implementation-specific enum values #214 ↩

[kainino0x]

@lokokung checked and thinks my logic is correct so I'm going to go ahead and close the PR and move this issue to non-breaking.