Re: [blink-dev] Intent to Extend Experiment: JavaScript Promise Integration

[Deepti Gandluri]

On Mon, Jun 24, 2024 at 12:47 PM Rick Byers  wrote:

> Hi Francis,
> We only do OT extensions for 3 milestones at a time
> .
> It sounds like there's been a meaningful change in the API that we need to
> validate, so extending for another 3 to 131 sounds OK to me if you'd like
> to do that, but that gets you only to October.
>
> Outside of JS / WASM features, we generally do not block on standards
> maturity when shipping new APIs, since the chromium project has a policy of
> limiting the cost on velocity that we're willing to pay in order to reach
> standards consensus. What do you think the harm would be in shipping this
> now and coming up with a versioning and/or breaking change strategy for any
> changes which are deemed necessary after that? It sounds like you already
> have customers relying on this feature (given the commitments you mention
> around evolution of the API while in OT), so it's unclear whether shipping
> and iterating would really be all that different in practice?
>

Apart from the API churn, the one requirement that we're missing for Phase
4 from the Wasm phases process

is
the spec document. The Wasm CG has a high level of consensus for this
feature, and while a reasonably complete overview exists, a full spec of
the feature does seem like a reasonable requirement to block on (IIUC for
JSPI the other requirements have already been met, or should be
non-controversial).

On the implementation front, there are a couple of upcoming changes to
improve performance that introduce significant code churn. Having the OT
extended even for a shorter duration would mean that we're able to validate
performance for current JSPI users, and get better bake time for fuzzer
coverage before shipping.

Thanks,
>Rick
>
> On Mon, Jun 24, 2024 at 1:31 PM Francis McCabe  wrote:
>
>> Contact emails...@chromium.org
>>
>> Explainer
>> https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md
>>
>> Specification
>> https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md
>>
>> Design docs
>>
>> https://docs.google.com/document/d/16Us-pyte2-9DECJDfGm5tnUpfngJJOc8jbj54HMqE9Y/edit#heading=h.n1atlriavj6v
>>
>> Summary
>>
>> Stack Switching denotes a technology that allows programs to suspend and
>> resume computation. This is an active area that is part of the WebAssembly
>> standards track. See https://github.com/WebAssembly/stack-switching and
>> https://github.com/WebAssembly/meetings/tree/main/stack. This particular
>> feature refers to the integration between JavaScript Promises and stack
>> switching. This is described in more detail in
>> https://docs.google.com/document/d/16Us-pyte2-9DECJDfGm5tnUpfngJJOc8jbj54HMqE9Y/edit#
>>
>>
>> Blink componentBlink>JavaScript>WebAssembly
>> 
>>
>> Search tagsstack switching
>> , Promise
>> , JSPI
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/809
>>
>> TAG review statusPending
>>
>> Chromium Trial NameWebAssemblyJSPromiseIntegration
>>
>> Origin Trial documentation link
>> https://github.com/WebAssembly/js-promise-integration
>>
>> WebFeature UseCounter namekV8WasmJavaScriptPromiseIntegration
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This spec is backed by a standardization effort. We do not plan to ship
>> the JSPI until it has been standardized by the W3C Wasm WG. However, post
>> standardization, we will depend on all browsers implementing the standard.
>>
>>
>> *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1850627)
>> Mozilla have started their own imlementation
>>
>> *WebKit*: No signal
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Activation
>>
>> Making use of JSPI requires some changes by WebAssembly-based developers
>> (no impact on JavaScript developers). Depending on their toolchain usage a
>> developer will need to modify their code. For Emscripten users, this is
>> likely to be minimal as support for JSPI exists in Emscripten.
>>
>>
>> Security
>>
>> 1. Control flow integrity. 2. Ensuring that JavaScript programs cannot
>> suspend via JSPI.
>>
>>
>> WebView application risks
>>
>> Does this intent 

Re: [blink-dev] Re: Intent to Implement and Ship

[Deepti Gandluri]

Thanks Alex!

On Wed, Mar 15, 2023 at 9:06 AM Alex Russell 
wrote:

> Hey Deepti,
>
> LGTM1
>
> I'm excited by the performance this intent will unlock.
>
> The explainer sort of hints at it, but what do you expect the impact to be
> on binary sizes based on compilers building in workarounds for missing
> relaxed instructions? How do you anticipate that developers will adopt to
> the presence/absence of these ops while balancing WASM binary size concerns?
>

We don't expect that this will result in significant binary size increases.
For the majority of the operations that are introduced here, they map 1:1
to non-relaxed fallbacks in the existing SIMD proposal. For code-gen, we
would generate fewer instructions overall because the existing operations
generate extra code for consistent handling of values across processors
(NaNs, +-infinity, and some other cases where the masks/bounds vary), this
in fact is the value add for the proposal that generating fewer (machine)
instructions gives us more performance for benchmarks that are sensitive to
it. The only two that don't have a fallback are the Dot product, and the
FMA operations. These don't have a direct fallback, and would be
comparatively expensive to emulate (mul+add in place of FMA, and a
more involved
lowering <https://github.com/WebAssembly/relaxed-simd/issues/52> for dot,
dotAdd operations of ~5 SIMD operations).

The absence of these ops should not be visible, or affect developers that
don't want to use these operations. For developers that are writing new
applications, they wouldn't run into them unless they need them as the
usage model is that they would have to explicitly invoke them using
compiler intrinsics, or special toolchain flags. Wasm tools would not be
generating relaxed SIMD ops by default, so these operations require users
to know about them or opt-in by using intrinsics. The trickier case is when
libraries already use them, and developers are using libraries pre-compiled
to Wasm in their applications, in that case the recommended option would be
to have a SIMD/Scalar fallback for the code that uses these operations.

>
> On TAG review, this *is* a web-visible change, so it would be helpful to
> keep that in mind in the future. Would encourage you to send the TAG an FYI
> about new language additions to help them stay informed and consider those
> capabilities when reviewing other features.
>

 Thanks for the clarification, is the right way to send an FYI through
the issue
tracker <https://github.com/w3ctag/design-reviews/issues>?

>
> Thanks.
>
> Alex
>
> On Thursday, March 9, 2023 at 11:42:18 PM UTC-8 Deepti Gandluri wrote:
>
>> On Thu, Mar 9, 2023 at 2:38 PM Mike Taylor 
>> wrote:
>>
>>> On 3/9/23 3:42 PM, Deepti Gandluri wrote:
>>>
>>> Quick note that I realized my title was accidentally cropped, it should
>>> be:
>>>
>>> "Intent to Implement and Ship: WebAssembly Relaxed SIMD".
>>>
>>> On Wed, Mar 8, 2023 at 4:11 PM Deepti Gandluri 
>>> wrote:
>>>
>>>> Contact emails gdee...@chromium.org, z...@chromium.org,
>>>> thiba...@chromium.org
>>>>
>>>> Explainer
>>>> https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md
>>>>
>>>> Specification
>>>> https://github.com/WebAssembly/relaxed-simd/tree/main/document
>>>>
>>>> Summary
>>>>
>>>> Relaxed SIMD extends the existing SIMD proposal to introduce vector
>>>> instructions that relax the strict determinism constraints of portable SIMD
>>>> to take better advantage of the underlying hardware. The operations
>>>> introduced in this proposal take advantage of widely available instruction
>>>> sets to accelerate compute workloads.
>>>>
>>>> Blink component Blink>JavaScript>WebAssembly
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly>
>>>>
>>>> TAG review Not required as per:
>>>> https://v8.dev/docs/feature-launch-process. This introduces an
>>>> additional set of vector operations to WebAssembly, and makes no API
>>>> changes.
>>>> Risks
>>>>
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>> *Gecko*: In development, enabled in nightly
>>>>
>>>> *WebKit*: No signal as per request for position:
>>>> mail-archive.com/webkit-dev@lists.webkit.org/msg30574.html
>>>>
>>> This should be updated to neutral, with concerns around potential compat
>>> issues 

[blink-dev] Re: Intent to Ship: WebAssembly Relaxed SIMD

[Deepti Gandluri]

On Mon, Mar 13, 2023 at 8:38 AM Paul Jensen  wrote:

> >> For FMA, on x86, everything from Haswell (2013) onwards, and Piledriver
> (2012) onwards on  AMD support native FMA operations. On ARM64, Neon
> support implies FMA would be natively supported as well (Neon is the
> baseline on ARM64 for being able to generate any vector instructions). On
> Arm32, the vfma/vfms instructions are supported on Armv7 onwards. So most
> recent processors have native support for FMA.
>
> Am I correct in interpreting this to mean that for devices made in the
> last decade, there wouldn't be substantial exposed entropy for FMA?


Yes, that is correct. Though a small caveat is that even though the
processor was released in 2013, consumer hardware does lag, so not strictly
a decade, but I would guess close to it.

>
> >> Regarding the dot product instruction, the SDOT instruction is natively
> supported on Armv8.2+ , we don't currently implement the AVX2-VNNI
> implementation at this time as a newer extension and the inability to test
> it on our bots. More details are outlined in this issue under "How does
> behavior differ across processors?".
>
> The "How does behavior differ across processors?" section lists three
> different options for dot products.  Which option is Chrome pursuing?  Do
> you know how much entropy is exposed here?
>

On x86/64, we use the lowerings for "x86/x86-64 processors with AVX
instruction set", so we don't support the most optimal lowering at this
time (though we are experimenting with them for prototyping/benchmarking).
On ARM64, we are using the "ARM64 processors with Dot Product extension"
option which is supported from ARMv8.2+. This is available in all the newer
Pixel Phones (2018 onwards), and on the ARM64 based M1/M2 Macbooks. The
older android phones, and ARM Chromebooks do not have native hardware
support for Dot product instructions. The reason we decided to support this
for the newer hardware was a between ~2-4x performance speedup (over
existing Wasm+SIMD) for benchmarks that are sensitive to this
<https://docs.google.com/presentation/d/1xlyO1ly2Fbo2Up5ZuV_BTSwiNpCwPygag09XQRjclSA/edit#slide=id.g1fee95a4c4f_0_0>
.

Thanks,
Deepti

>
> On Friday, March 10, 2023 at 2:39:03 AM UTC-5 Deepti Gandluri wrote:
>
>> Pasting, and responding to entropy questions from the previous thread:
>>
>> >> For most of the exposed entropy, we already expose this via the
>> User-Agent string, or the Arch UA Client Hint. Can you say more about
>> "Differences between hardware that has native FMA support, and hardware
>> that does not." and "whether the Dot product extension is supported in the
>> most optimal codegen" - any idea what the distributions would look there
>> there?
>>
>> For FMA, on x86, everything from Haswell (2013) onwards, and Piledriver
>> (2012) onwards on  AMD support native FMA operations. On ARM64, Neon
>> support implies FMA would be natively supported as well (Neon is the
>> baseline on ARM64 for being able to generate any vector instructions). On
>> Arm32, the vfma/vfms instructions are supported on Armv7 onwards. So most
>> recent processors have native support for FMA.
>>
>> Regarding the dot product instruction, the SDOT instruction is natively
>> supported on Armv8.2+ , we don't currently implement the AVX2-VNNI
>> implementation at this time as a newer extension and the inability to test
>> it on our bots. More details are outlined in this issue
>> <https://github.com/WebAssembly/relaxed-simd/issues/52> under "How does
>> behavior differ across processors?".
>>
>> >> As to compat, "code compiled for one browser works differently on a
>> different browser" - this sounds a little bit scary! Do we have any ideas
>> on how to minimize (I assume preventing isn't a reality) this outcome?
>>
>> The proposal tries to minimize this by being very prescriptive of optimal
>> instruction sequences, for consistent outcome. While we expect browsers
>> engines to use this set of instructions in their code generation, loosening
>> the determinism means that we don't have a way to necessarily guarantee
>> that.
>>
>> Thanks,
>> Deepti
>>
>>
>> On Thu, Mar 9, 2023 at 11:06 PM Deepti Gandluri 
>> wrote:
>>
>>> Contact emailsgdee...@chromium.org, z...@chromium.org,
>>> thiba...@chromium.org
>>>
>>> Explainer
>>> https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md
>>>
>>> Specification
>>> https://github.com/WebAssembly/relaxed-simd/tree/ma

Re: [blink-dev] Re: Intent to Implement and Ship

[Deepti Gandluri]

On Thu, Mar 9, 2023 at 2:38 PM Mike Taylor  wrote:

> On 3/9/23 3:42 PM, Deepti Gandluri wrote:
>
> Quick note that I realized my title was accidentally cropped, it should
> be:
>
> "Intent to Implement and Ship: WebAssembly Relaxed SIMD".
>
> On Wed, Mar 8, 2023 at 4:11 PM Deepti Gandluri 
> wrote:
>
>> Contact emails gdee...@chromium.org, z...@chromium.org,
>> thiba...@chromium.org
>>
>> Explainer
>> https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md
>>
>> Specification
>> https://github.com/WebAssembly/relaxed-simd/tree/main/document
>>
>> Summary
>>
>> Relaxed SIMD extends the existing SIMD proposal to introduce vector
>> instructions that relax the strict determinism constraints of portable SIMD
>> to take better advantage of the underlying hardware. The operations
>> introduced in this proposal take advantage of widely available instruction
>> sets to accelerate compute workloads.
>>
>> Blink component Blink>JavaScript>WebAssembly
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly>
>>
>> TAG review Not required as per:
>> https://v8.dev/docs/feature-launch-process. This introduces an
>> additional set of vector operations to WebAssembly, and makes no API
>> changes.
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> *Gecko*: In development, enabled in nightly
>>
>> *WebKit*: No signal as per request for position:
>> mail-archive.com/webkit-dev@lists.webkit.org/msg30574.html
>>
> This should be updated to neutral, with concerns around potential compat
> issues (it was manually moved to the new standards-position repo:
> https://github.com/WebKit/standards-positions/issues/4#issuecomment-1170364495
> ).
>

Thanks for the pointer, I missed the issue being moved over.

>
>> *Web developers*: Strongly positive, Proposal in Phase 3 in the
>> WebAssembly CG the proposal was incubated to address some of the
>> developer/user requests from the previous SIMD proposal.
>>
>> *Other signals*: Proposal voted to a provisional phase 4 as per meeting
>> notes in the February 14th CG meeting (notes:
>> https://github.com/WebAssembly/meetings/blob/main/main/2023/CG-02-14.md).
>> The feature has consensus in the CG, but the vote is provisional till the
>> formal spec is up to date (Tracking issue:
>> https://github.com/WebAssembly/relaxed-simd/issues/134, PRs also in
>> flight).
>>
>> 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? No
>>
>>
>> Debuggability
>>
>> Supported instructions are enabled in Liftoff, and are visible to
>> DevTools for debuggability.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)? Yes
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ? Not applicable, tested by WebAssembly spec tests
>>
>> Flag name V8: --wasm-relaxed-simd Chrome:
>> Features::kWebAssemblyRelaxedSimd
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://bugs.chromium.org/p/v8/issues/detail?id=12284
>>
>> Estimated milestones
>>
>> 114
>>
>> Anticipated spec changes
>>
>> No anticipated spec changes, but some potential for compat issues based
>> on hardware, more details in this Entropy.md
>> <https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Entropy.md>,
>> and the linked issues.
>>
> Thanks for the Entropy.md doc - it's incredibly helpful.
>
> For most of the exposed entropy, we already expose this via the User-Agent
> string, or the Arch UA Client Hint. Can you say more about "Differences
> between hardware that has native FMA support, and hardware that does not."
> and "whether the Dot product extension is supported in the most optimal
> codegen" - any idea what the distributions would look there there?
>
> As to compat, "code compiled for one browser works differently on a
> different browser" - this sounds a little bit scary! Do we have any ideas
> on how to minimize (I assume preventing isn't a reality) this outcome?
>

I re-posted this thread to fix the title, and have pasted+responded to this
in the newer thread. Sorry for the

[blink-dev] Re: Intent to Ship: WebAssembly Relaxed SIMD

[Deepti Gandluri]

Pasting, and responding to entropy questions from the previous thread:

>> For most of the exposed entropy, we already expose this via the
User-Agent string, or the Arch UA Client Hint. Can you say more about
"Differences between hardware that has native FMA support, and hardware
that does not." and "whether the Dot product extension is supported in the
most optimal codegen" - any idea what the distributions would look there
there?

For FMA, on x86, everything from Haswell (2013) onwards, and Piledriver
(2012) onwards on  AMD support native FMA operations. On ARM64, Neon
support implies FMA would be natively supported as well (Neon is the
baseline on ARM64 for being able to generate any vector instructions). On
Arm32, the vfma/vfms instructions are supported on Armv7 onwards. So most
recent processors have native support for FMA.

Regarding the dot product instruction, the SDOT instruction is natively
supported on Armv8.2+ , we don't currently implement the AVX2-VNNI
implementation at this time as a newer extension and the inability to test
it on our bots. More details are outlined in this issue
<https://github.com/WebAssembly/relaxed-simd/issues/52> under "How does
behavior differ across processors?".

>> As to compat, "code compiled for one browser works differently on a
different browser" - this sounds a little bit scary! Do we have any ideas
on how to minimize (I assume preventing isn't a reality) this outcome?

The proposal tries to minimize this by being very prescriptive of optimal
instruction sequences, for consistent outcome. While we expect browsers
engines to use this set of instructions in their code generation, loosening
the determinism means that we don't have a way to necessarily guarantee
that.

Thanks,
Deepti


On Thu, Mar 9, 2023 at 11:06 PM Deepti Gandluri 
wrote:

> Contact emailsgdee...@chromium.org, z...@chromium.org,
> thiba...@chromium.org
>
> Explainer
> https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md
>
> Specification
> https://github.com/WebAssembly/relaxed-simd/tree/main/document
>
> Summary
>
> Relaxed SIMD extends the existing SIMD proposal to introduce vector
> instructions that relax the strict determinism constraints of portable SIMD
> to take better advantage of the underlying hardware. The operations
> introduced in this proposal take advantage of widely available instruction
> sets to accelerate compute workloads.
>
> Blink componentBlink>JavaScript>WebAssembly
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly>
>
> TAG reviewNot required as per: https://v8.dev/docs/feature-launch-process.
> This introduces an additional set of vector operations to WebAssembly, and
> makes no API changes.
> Risks
>
>
> Interoperability and Compatibility
>
> *Gecko*: In development, enabled in nightly
>
> *WebKit*: Neutral as per issue comment
> <https://github.com/WebKit/standards-positions/issues/4#issuecomment-1170364495>
>
> *Web developers*: Strongly positive, Proposal in Phase 3 in the
> WebAssembly CG the proposal was incubated to address some of the
> developer/user requests from the previous SIMD proposal.
>
> *Other signals*: Proposal voted to a provisional phase 4 as per meeting
> notes in the February 14th CG meeting (notes:
> https://github.com/WebAssembly/meetings/blob/main/main/2023/CG-02-14.md).
> The feature has consensus in the CG, but the vote is provisional till the
> formal spec is up to date (Tracking issue:
> https://github.com/WebAssembly/relaxed-simd/issues/134, PRs also in
> flight).
>
> 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? No
>
>
>
> Debuggability
>
> Supported instructions are enabled in Liftoff, and are visible to DevTools
> for debuggability.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
> ?Not applicable, tested by WebAssembly spec tests
>
> Flag nameV8: --wasm-relaxed-simdChrome: Features::kWebAssemblyRelaxedSimd
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=12284
>
> Estimated milestones
>
> 114
>
> Anticipated spec changes
>
> No anticipated spec changes, but some potential for compat issues based on
> hardware, more details in this Entropy.md
> <https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relax

[blink-dev] Intent to Ship: WebAssembly Relaxed SIMD

[Deepti Gandluri]

Contact emailsgdee...@chromium.org, z...@chromium.org, thiba...@chromium.org

Explainer
https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md

Specificationhttps://github.com/WebAssembly/relaxed-simd/tree/main/document

Summary

Relaxed SIMD extends the existing SIMD proposal to introduce vector
instructions that relax the strict determinism constraints of portable SIMD
to take better advantage of the underlying hardware. The operations
introduced in this proposal take advantage of widely available instruction
sets to accelerate compute workloads.

Blink componentBlink>JavaScript>WebAssembly


TAG reviewNot required as per: https://v8.dev/docs/feature-launch-process.
This introduces an additional set of vector operations to WebAssembly, and
makes no API changes.
Risks


Interoperability and Compatibility

*Gecko*: In development, enabled in nightly

*WebKit*: Neutral as per issue comment


*Web developers*: Strongly positive, Proposal in Phase 3 in the WebAssembly
CG the proposal was incubated to address some of the developer/user
requests from the previous SIMD proposal.

*Other signals*: Proposal voted to a provisional phase 4 as per meeting
notes in the February 14th CG meeting (notes:
https://github.com/WebAssembly/meetings/blob/main/main/2023/CG-02-14.md).
The feature has consensus in the CG, but the vote is provisional till the
formal spec is up to date (Tracking issue:
https://github.com/WebAssembly/relaxed-simd/issues/134, PRs also in flight).

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? No



Debuggability

Supported instructions are enabled in Liftoff, and are visible to DevTools
for debuggability.


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?Not applicable, tested by WebAssembly spec tests

Flag nameV8: --wasm-relaxed-simdChrome: Features::kWebAssemblyRelaxedSimd

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=12284

Estimated milestones

114

Anticipated spec changes

No anticipated spec changes, but some potential for compat issues based on
hardware, more details in this Entropy.md
,
and the linked issues.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5082417973952512

-- 
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/CALi9WK8u8UxgQemmHvod6FMDc82ZS%2B9boNB-Y-kxw2JTpuL_sA%40mail.gmail.com.

[blink-dev] Re: Intent to Implement and Ship

[Deepti Gandluri]

Quick note that I realized my title was accidentally cropped, it should be:

"Intent to Implement and Ship: WebAssembly Relaxed SIMD".

On Wed, Mar 8, 2023 at 4:11 PM Deepti Gandluri  wrote:

> Contact emailsgdee...@chromium.org, z...@chromium.org,
> thiba...@chromium.org
>
> Explainer
> https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md
>
> Specification
> https://github.com/WebAssembly/relaxed-simd/tree/main/document
>
> Summary
>
> Relaxed SIMD extends the existing SIMD proposal to introduce vector
> instructions that relax the strict determinism constraints of portable SIMD
> to take better advantage of the underlying hardware. The operations
> introduced in this proposal take advantage of widely available instruction
> sets to accelerate compute workloads.
>
> Blink componentBlink>JavaScript>WebAssembly
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly>
>
> TAG reviewNot required as per: https://v8.dev/docs/feature-launch-process.
> This introduces an additional set of vector operations to WebAssembly, and
> makes no API changes.
> Risks
>
>
> Interoperability and Compatibility
>
> *Gecko*: In development, enabled in nightly
>
> *WebKit*: No signal as per request for position:
> mail-archive.com/webkit-dev@lists.webkit.org/msg30574.html
>
> *Web developers*: Strongly positive, Proposal in Phase 3 in the
> WebAssembly CG the proposal was incubated to address some of the
> developer/user requests from the previous SIMD proposal.
>
> *Other signals*: Proposal voted to a provisional phase 4 as per meeting
> notes in the February 14th CG meeting (notes:
> https://github.com/WebAssembly/meetings/blob/main/main/2023/CG-02-14.md).
> The feature has consensus in the CG, but the vote is provisional till the
> formal spec is up to date (Tracking issue:
> https://github.com/WebAssembly/relaxed-simd/issues/134, PRs also in
> flight).
>
> 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? No
>
>
>
> Debuggability
>
> Supported instructions are enabled in Liftoff, and are visible to DevTools
> for debuggability.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
> ?Not applicable, tested by WebAssembly spec tests
>
> Flag nameV8: --wasm-relaxed-simdChrome: Features::kWebAssemblyRelaxedSimd
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=12284
>
> Estimated milestones
>
> 114
>
> Anticipated spec changes
>
> No anticipated spec changes, but some potential for compat issues based on
> hardware, more details in this Entropy.md
> <https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Entropy.md>,
> and the linked issues.
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5082417973952512
>

-- 
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/CALi9WK_SOE5jAVCPydhY0Xn4S6P2rr_W9qhQhN5tA0Ew9vJEdg%40mail.gmail.com.

[blink-dev] Intent to Implement and Ship

[Deepti Gandluri]

Contact emailsgdee...@chromium.org, z...@chromium.org, thiba...@chromium.org

Explainer
https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md

Specificationhttps://github.com/WebAssembly/relaxed-simd/tree/main/document

Summary

Relaxed SIMD extends the existing SIMD proposal to introduce vector
instructions that relax the strict determinism constraints of portable SIMD
to take better advantage of the underlying hardware. The operations
introduced in this proposal take advantage of widely available instruction
sets to accelerate compute workloads.

Blink componentBlink>JavaScript>WebAssembly


TAG reviewNot required as per: https://v8.dev/docs/feature-launch-process.
This introduces an additional set of vector operations to WebAssembly, and
makes no API changes.
Risks


Interoperability and Compatibility

*Gecko*: In development, enabled in nightly

*WebKit*: No signal as per request for position:
mail-archive.com/webkit-dev@lists.webkit.org/msg30574.html

*Web developers*: Strongly positive, Proposal in Phase 3 in the WebAssembly
CG the proposal was incubated to address some of the developer/user
requests from the previous SIMD proposal.

*Other signals*: Proposal voted to a provisional phase 4 as per meeting
notes in the February 14th CG meeting (notes:
https://github.com/WebAssembly/meetings/blob/main/main/2023/CG-02-14.md).
The feature has consensus in the CG, but the vote is provisional till the
formal spec is up to date (Tracking issue:
https://github.com/WebAssembly/relaxed-simd/issues/134, PRs also in flight).

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? No



Debuggability

Supported instructions are enabled in Liftoff, and are visible to DevTools
for debuggability.


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?Not applicable, tested by WebAssembly spec tests

Flag nameV8: --wasm-relaxed-simdChrome: Features::kWebAssemblyRelaxedSimd

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=12284

Estimated milestones

114

Anticipated spec changes

No anticipated spec changes, but some potential for compat issues based on
hardware, more details in this Entropy.md
,
and the linked issues.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5082417973952512

-- 
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/CALi9WK9bJKKMinnRGFw5PWQimoZBfHEcMjQ7CDOU4hdcWo%3DekQ%40mail.gmail.com.