>> 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? >> 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 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 <gdee...@chromium.org> > 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/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/cda5786f-0c5d-4515-90ae-39111856adc9n%40chromium.org.
