On Wednesday, October 23, 2024 at 8:21:22 AM UTC-7 Yoav Weiss wrote:
> Can y'all flip the review bits for
> privacy/security/enterprise/testing/debuggability?
>
Done!
On Wed, Oct 23, 2024 at 11:23 AM Alex Russell <slightly...@chromium.org>
wrote:
> Thanks for the explanation, Geoff. We discussed at today's OWNERS meeting,
> and with that conversation I'm comfortable with the change. LGTM1
>
> On Wednesday, October 23, 2024 at 8:21:22 AM UTC-7 Yoav Weiss wrote:
>
>> Can y'all flip the review bits for
>> privacy/security/enterprise/testing/debuggability?
>>
>> On Thursday, October 17, 2024 at 12:05:03 PM UTC-7 Geoff Lang wrote:
>>
>>> 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 visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BPGBXss7ZTcRh_fWH%2BkfXKZ0usj_fV6u-W8HEuOEST_z6EFog%40mail.gmail.com.
