I'll describe a use case that become better/possible:
The user creates a texture with the 'bgra8unorm' format but as an
additional view format of 'rgba8unorm-srgb':
const texture = device.createTexture({
size: [4, 4],
format: 'rgba8unorm',
usage: GPUTextureUsage.RENDER_ATTACHMENT |
GPUTextureUsage.TEXTURE_BINDING | GPUTextureUsage.STORAGE_BINDING,
viewFormats: ['rgba8unorm-srgb'],
});
const view = texture.createView({
format: 'rgba8unorm-srgb',
});
If the user creates this view of this texture using the 'rgba8unorm-srgb'
format, it won't be usable as a storage texture despite requesting the
texture having STORAGE_BINDING usage because 'rgba8unorm-srgb' does not
support this usage. By adding a usage field to view creation, the browser
can do validation up-front that the usage is compatible and allow users to
specify even smaller subsets of usage that are specific to how the view
will be used:
const view = texture.createView({
format: 'rgba8unorm-srgb',
usage: GPUTextureUsage.RENDER_ATTACHMENT,
});
This also mirrors how other graphics APIs work, usage flags are also
creation parameters to view creation. It allows more optimizations at the
graphics driver level.
There's some more discussion in this github issue:
https://github.com/gpuweb/gpuweb/issues/4426
Let me know if there's anything else you want to know or if I should write
this up somewhere else.
Thanks,
Geoff
On Thu, Oct 17, 2024 at 6:20 AM Alex Russell <slightly...@chromium.org>
wrote:
> Is there a description somewhere of what problem this solves? I'm having
> trouble grokking why this is useful.
>
> Best,
>
> Alex
>
> On Thursday, October 17, 2024 at 12:54:20 AM UTC+5:30 Chromestatus wrote:
>
>> Contact emails geoffl...@google.com
>>
>> Explainer None
>>
>> Specification
>> https://github.com/gpuweb/gpuweb/commit/b39d86d356eb759d7564bc7c808ca62fce8bbf3e
>>
>> Summary
>>
>> Adds an optional field to WebGPU texture view creation to request a
>> subset of the usage flags from the source texture. By default, texture view
>> usage inherits from the source texture but there are view formats which can
>> be incompatible with the full set of inherited usages. Adding a usage field
>> to texture view creation allows the user request a subset of the source
>> texture's usages that are valid with the view format and specific to their
>> intended usage of the texture view. WebGPU implementations can also
>> optimize the creation of low level resources and improve performance when
>> using views with more specialized usage flags.
>>
>>
>> Blink component Blink>WebGPU
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebGPU>
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This feature has been approved in W3C GPU for the Web WG meetings
>> including participants from Safari and Firefox:
>> https://github.com/gpuweb/gpuweb/wiki/GPU-Web-2024-07-24#createtexture-does-not-validate-viewformats-against-usage-4426
>>
>>
>> *Gecko*: No signal
>>
>> *WebKit*: Closed Without a Position (
>> https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933)
>>
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)? No
>>
>> All platforms will eventually have support. Will immediately be available
>> on Android, Android WebView, ChromeOS, Mac, and Windows, where hardware
>> support is available. Linux is planned to have WebGPU support in the
>> future, so this feature will become available when WebGPU does.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ? Yes
>>
>> WebGPU/WGSL have a conformance test suite (https://github.com/gpuweb/cts)
>> that is regularly pulled into Chromium and part of the testing of Dawn/Tint
>> in Chromium. While the CTS can be embedded in WPT, the WebGPU team opted to
>> keep it separate in Chromium testing to use a customized harness for
>> robustness and performance. Tests were added in this PR:
>> https://github.com/gpuweb/cts/commit/1746bcbc10a809cbadb3b131675b885ed08d9da5
>>
>>
>> Flag name on chrome://flags None
>>
>> Finch feature name WebGPU.Enabled:UnsafeFeatures
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://bugs.chromium.org/363903526
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5155252832305152?gate=5152335609987072
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.com>.
>>
>
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BPGBXvSL_C5%2B7SPkcpv%2BQ7uMihX3QqjBKaJjQ2sT494%3DcBKhA%40mail.gmail.com.
