Let's discuss requirements, timeline for Phase 4

[dtig]

Starting a discussion to figure out what's needed for Phase 4!

Aside from the stated requirements for Phase 4 (spec finalized, support from browser VMs, toolchain support for remaining instructions) I'm wondering if there are other things that will help us move us further along towards standardizing this proposal. Some things I can think of that we could tackle at the subgroup level:

• A potential vote for final instruction set - we probably want most/all of the instructions in the proposal, but would be nice to have an explicit vote for the record. This would also be useful as a signal that we won't be adding any new instructions, and can move forward to standardizing the proposal.
• A discussion in a future meeting about usage patterns, or potential compat issues and how to navigate them
• Should we have a minimum hardware requirement for supporting the relaxed-simd proposal? For example, for the fixed-width SIMD proposal, we landed on SSE4.1/Neon as a baseline. For this proposal, we could revisit this given the newer instructions introduced. Perhaps have FMA as a baseline requirement?
• Vote on any open issues
• Anything else?

[ngzhian]

Should we have a minimum hardware requirement for supporting the relaxed-simd proposal? For example, for the fixed-width SIMD proposal, we landed on SSE4.1/Neon as a baseline. For this proposal, we could revisit this given the newer instructions introduced. Perhaps have FMA as a baseline requirement?

Hm, FMA requirement might be too strict. If we have hardware FMA requirement, then we won't need to define a relaxed FMA, since any hardware that doesn't have FMA won't be able to run these instructions anyway. However, the spec doesn't really have a way to say minimum hardware requirement, does it?

[dtig]

The spec doesn't have a way to talk about minimum hardware requirements, this is more along the lines of engine implementation guidelines for consistent behavior (to the extent possible) and performance expectations. While baseline hardware requirements are not as specific as implementation defined limits for example, I'd be interested to have a discussion about what subset of hardware is this proposal targeting as a baseline, and what are performance expectations if we don't. For example, for hardware that has none of the newer instruction sets, is it worthwhile to run relaxed-simd code, or just default to portable SIMD? This would also have an easy side effect of resolving open issues like we have for adding a deterministic FMA.

[ngzhian]

A potential vote for final instruction set - we probably want most/all of the instructions in the proposal, but would be nice to have an explicit vote for the record. This would also be useful as a signal that we're

Your message got cut off, it looks like you're trying to say "... we're aligned"?

[dtig]

Oops, I'm not sure what happened there text probably got cut off by accident. I've updated the OP.

[Maratyszcza]

• Should we have a minimum hardware requirement for supporting the relaxed-simd proposal? For example, for the fixed-width SIMD proposal, we landed on SSE4.1/Neon as a baseline. For this proposal, we could revisit this given the newer instructions introduced.

De-facto the Relaxed SIMD treats SSE4.1 / NEON as the baseline too, as instruction proposals used the currently targeted by Chrome & FireFox for WAsm SIMD ISAs as the baseline.

[dtig]

Right, but are we expected to see performance wins from having a subset of relaxed operations on baseline hardware? I expect yes, but I'm curious to hear if they're significant at the application level.

[Maratyszcza]

• Vote on any open issues

Technically, all issues are open (we didn't close them when instructions were added to the spec). #77 is the only one not yet in the spec.

[penzn]

In prior experience we made sure we'd make a decision to add open suggestions in or set them aside.

[penzn]

I am not sure we have to up the requirements, but I think it would be good to be upfront about potential requirements for instructions that require more than SSE to be efficient or get rounded differently. The latter is obvious - we are "relaxing" allowed output because we want to provide an option to support those hardware features. In my opinion being upfront about accelerating instructions via newer ISAs is important too, otherwise we are effectively saying we are adding instructions that provide nothing new.