Marking non-substantative for IPR as it lifts a restriction and was contributed in discussions many times previously.

Previews, as seen when this build job started (aec2074):
WebGPU webgpu.idl | Explainer | Correspondence Reference
WGSL grammar.js | wgsl.lalr.txt

@mwyrzykowski I think that comment is pretty unambiguous:

Since people want to support WebGPU on all versions of Windows 10, we'll need to make this feature be a WebGPU extension.

(https://github.com/gpuweb/gpuweb/wiki/System-Requirements and AFAICT Chrome still supports Windows 1507)

Did you have a specific concern about it? IIUC it's not possible to query UnalignedBlockTexturesSupported at all on those older OSes so the only other option would be to drop Core WebGPU support on older OSes.

Did you have a specific concern about it?

It’s unfortunate to introduce fragmentation for such a small feature but given the value, I am fine with it :)

It’s unfortunate to introduce fragmentation for such a small feature but given the value, I am fine with it :)

An interesting observation is that the alignment requirements only apply to the BC formats. These are the only formats that are supported under D3D11 & D3D12, so they are the only formats that can be subject to that constraint in practice.

A potential simplification would be to only require alignment of BC formats, and to expose the "texture-compression-bc-unaligned" extension to relax that requirement.

Applications that target ASTC or ETC formats then do not have to worry about querying and enabling the extension, since they are unaffected.

If this seems like a good idea I'd be happy to do the necessary work to update the spec and the test suite.

Oh, that's a good point. Yes, that seems preferable!

It would mean we're adding unaligned ASTC/ETC2 textures to core, which is great but means we need some feature detection. This came up elsewhere recently so I've filed #6337 about it.

@castano We discussed this in the working group meeting and there's a concern that it'll be more complicated to do it that way because, if this is also disallowed by OpenGL ES 3.1, then the validation will be affected by TWO features, texture-compression-bc-unaligned and core-features-and-limits.

We'll want more info on whether GLES3.1 disallows this before deciding which path to take.

@castano We discussed this in the working group meeting and there's a concern that it'll be more complicated to do it that way because, if this is also disallowed by OpenGL ES 3.1, then the validation will be affected by TWO features, texture-compression-bc-unaligned and core-features-and-limits.

From the developer point of view it's certainly simpler to just consider one feature. It would have been nice if the constrain in WebGPU only existed for BC formats, but relaxing it now depending on format and OS/version adds unnecessary complexity. A single feature would serve developers better.

We'll want more info on whether GLES3.1 disallows this before deciding which path to take.

I believe GLES never imposed this constraint. However, WebGL did have that requirement for the BC formats:

For compatibility reasons, the width and the height of the top level mip map are required to be a multiple of 4.

Note that this language is not present in the ASTC and ETC WebGL extensions.

• KN: Ignacio observed that the restriction only comes from D3D and D3D only allows BC, so we could make the other texture compression formats unaligned by defaults. Less features for people to deal with.
• JB: Makes sense
• MW: thumbs up
• CW: One concern, on our implementation we did not enable this for OpenGL. I think this would need to be disallowed on Compat. So it's more complicated than that, think it's a mess and one feature is simpler.
• JB: We can to buffer-to-texture copies to compressed textures. Do we need to have interesting language to describe how they work?
• CW/KN: No, we already have that because it's already handled for smaller mip levels which are not size-aligned.
• KN: Think it's still nice to enable by default for Core.
• CW: Something that's come up recently is that we should do a feature level. I'll bring this up at F2F: if we define a new feature level, what would you like to be included? Maybe texture-compression-unaligned is part of that.
• CW: Seems that we need more time to investigate OpenGL.

Testing on OpenGL with this WIP CL, the tests seem to pass on the Pixel 10 GLES driver, but not the Pixel 6 one with failures like below.

[37/7924] webgpu:api,operation,command_buffer,image_copy:compressed_textures,unaligned_mip_level_0:initMethod="CopyB2T";checkMethod="FullCopyT2B";format="astc-5x5-unorm" failed unexpectedly 16.5731s (worker 1):
    - (in subcase: copyCase={"originInBlocks":{"x":0,"y":0},"copySizeInBlocks":{"width":4,"height":4}}) INFO: subcase ran
  --> (in subcase: copyCase={"originInBlocks":{"x":3,"y":0},"copySizeInBlocks":{"width":1,"height":4}}) EXPECTATION FAILED: array is entirely 0 so likely nothing was tested: actualTexture
          at arrayNotAllTheSameValue (http://127.0.0.1:40969/third_party/webgpu-cts/src/webgpu/texture_test_utils.js:238:19)
          at http://127.0.0.1:40969/third_party/webgpu-cts/src/webgpu/texture_test_utils.js:249:45
          at async ImageCopyTest.finalize (http://127.0.0.1:40969/third_party/webgpu-cts/src/common/framework/fixture.js:92:17)
          at async RunCaseSpecific.runTest (http://127.0.0.1:40969/third_party/webgpu-cts/src/common/internal/test_group.js:263:17)
    - (in subcase: copyCase={"originInBlocks":{"x":3,"y":0},"copySizeInBlocks":{"width":1,"height":4}}) EXPECTATION FAILED: array is entirely 0 so likely nothing was tested: expectedTexture
          at arrayNotAllTheSameValue (http://127.0.0.1:40969/third_party/webgpu-cts/src/webgpu/texture_test_utils.js:238:19)
          at http://127.0.0.1:40969/third_party/webgpu-cts/src/webgpu/texture_test_utils.js:250:45
          at async ImageCopyTest.finalize (http://127.0.0.1:40969/third_party/webgpu-cts/src/common/framework/fixture.js:92:17)
          at async RunCaseSpecific.runTest (http://127.0.0.1:40969/third_party/webgpu-cts/src/common/internal/test_group.js:263:17)
    - (in subcase: copyCase={"originInBlocks":{"x":3,"y":0},"copySizeInBlocks":{"width":1,"height":4}}) INFO: subcase ran
    - (in subcase: copyCase={"originInBlocks":{"x":0,"y":3},"copySizeInBlocks":{"width":4,"height":1}}) INFO: subcase ran
    - (in subcase: copyCase={"originInBlocks":{"x":3,"y":3},"copySizeInBlocks":{"width":1,"height":1}}) EXPECTATION FAILED: array is entirely 0 so likely nothing was tested: actualTexture
        at (elided: only 2 shown)
    - (in subcase: copyCase={"originInBlocks":{"x":3,"y":3},"copySizeInBlocks":{"width":1,"height":1}}) EXPECTATION FAILED: array is entirely 0 so likely nothing was tested: expectedTexture
        at (elided: only 2 shown)
    - (in subcase: copyCase={"originInBlocks":{"x":3,"y":3},"copySizeInBlocks":{"width":1,"height":1}}) INFO: subcase ran
    - (in subcase: copyCase={"originInBlocks":{"x":0,"y":0},"copySizeInBlocks":{"width":1,"height":1}}) EXPECTATION FAILED: array is entirely 0 so likely nothing was tested: actualTexture
        at (elided: only 2 shown)
    - (in subcase: copyCase={"originInBlocks":{"x":0,"y":0},"copySizeInBlocks":{"width":1,"height":1}}) EXPECTATION FAILED: array is entirely 0 so likely nothing was tested: expectedTexture
        at (elided: only 2 shown)
    - (in subcase: copyCase={"originInBlocks":{"x":0,"y":0},"copySizeInBlocks":{"width":1,"height":1}}) INFO: subcase ran

Given this I'd feel more comfortable if we could enable / disable the feature based on drivers as well to avoid exposing the buggy feature (so that would mean texture-compression-unaligned instead of texture-compression-bc-unaligned). I also think that having texture-compression-unaligned is simpler for developers because they have one thing to check for to know if they can use unaligned compressed textures, instead of having to do !BC || texture-compression-bc-unaligned which they'll likely forget to do.

kainino0x marked as non substantive for IPR from ash-nazg.

I can't find anything about restrictions in OpenGL or OpenGL ES on the size of the texture (at base mip level) being a multiple of the block size, not even in EXT_texture_compression_s3tc.

Just a note: To reduce the illusion of fragmentation a bit, we could make it so that you can't create a device with ASTC or ETC2 without texture-compression-unaligned, since it seems no such devices exist. That is, for a device request with texture-compression-astc or texture-compression-etc2, texture-compression-unaligned gets enabled automatically. If needed this could also require core-features-and-limits to be requested (implicitly or explicitly) as well.

This doesn't have to be done now, it can wait until we have clearer results. It would just have a minor temporary impact on cross-browser compatibility if it comes after multiple browsers ship texture-compression-unaligned.

Is there enough alignment on having the feature be texture-compression-unaligned and an optional feature such that we can resolve to land this PR offline? @jimblandy @mwyrzykowski @kainino0x ?

I'm happy with it, and it hasn't changed since last approvals, but mainly want to get a stamp from @jimblandy now that there is an answer to the OpenGL question.

I'll fix the merge conflict to make this landable.