Yes, I'm working on a proposal to address trial participation for third-party, or "indirect", origins. I hope to have something soon. I've created crbug.com/1069623 <https://bugs.chromium.org/p/chromium/issues/detail?id=1069623> to track the issue. Folks that are interested are welcome to follow or comment on that issue.
Thanks, Jason On Thu, Apr 9, 2020 at 3:50 AM Yoav Weiss <[email protected]> wrote: > Thanks Mounir! :) > > *LGTM to experiment* M84-M86 > > +Jason Chase <[email protected]> on the subject of "indirect" Origin > Trials. That's something we've seen as a hurdle on other fronts as well > (e.g. third party vendors who want to experiment, but need their customers > to sign up). > > On Wed, Apr 8, 2020 at 8:36 PM Deepti Gandluri <[email protected]> > wrote: > >> Thanks Mounir, adjusting the experimental timeline to the recommended >> 3-release trial, and then optionally extending based on feedback sounds >> reasonable to me. >> >> On Tuesday, April 7, 2020 at 4:40:18 PM UTC-7, Mounir Lamouri wrote: >>> >>> Thank you for the details, Deepti. I'm not an owner but I would >>> recommend going for a 3-release Origin Trial and assess the situation then >>> and decide whether extending makes sense. If there isn't enough usage by >>> then, extending would probably be an easy call. It seems better to me to >>> assess it then than preemptively set the experiment length to 5 releases >>> assuming the usage and feedback will take some time to ramp up. >>> >>> -- Mounir >>> >>> On Fri, 3 Apr 2020 at 13:21, Deepti Gandluri <[email protected]> >>> wrote: >>> >>>> The partners we have lined up, currently have a (mostly) full SIMD >>>> version of their applications ready. So they would be able to enable this >>>> right away. >>>> >>>> There are a couple of issues I was hoping to address with a longer >>>> trial, for the partners that currently have an in progress implementation, >>>> as well as for partners where to get feedback, there is a level of >>>> indirection involved when it comes to how users can take advantage of this. >>>> To clarify what I mean by the second use case - for partners like >>>> Halide <https://github.com/halide/Halide>, and Tensorflow.js >>>> <https://blog.tensorflow.org/2020/03/introducing-webassembly-backend-for-tensorflow-js.html>, >>>> which have WebAssembly backends with experimental SIMD support, to get >>>> feedback their users will have to sign up for an origin trial, as they >>>> serve as backends/libraries and are not end users themselves. So some of >>>> that buffer was to ensure we can reach a larger number of users - I'm >>>> somewhat unsure how to account for that type of indirection as I haven't >>>> found many other examples where this is the case, so feedback here is >>>> welcome. >>>> >>>> With respect to "ongoing standardization effort", I should have been >>>> clearer there. The proposal is currently at Phase 3 >>>> <https://github.com/WebAssembly/meetings/blob/master/process/phases.md#3-implementation-phase-community--working-group>, >>>> and the standardization effort here refers to moving to Phase 4 >>>> <https://github.com/WebAssembly/meetings/blob/master/process/phases.md#4-standardize-the-feature-working-group>, >>>> the requirement for which is that there needs to be one other Web VM that >>>> implements this. At this point, the shape of the API is quite stable, we >>>> have an implementation in both V8, as well as the WebAssembly LLVM >>>> toolchain, and we are waiting on more engine implementations to move the >>>> proposal forward. >>>> >>>> On Friday, April 3, 2020 at 11:05:32 AM UTC-7, Mounir Lamouri wrote: >>>>> >>>>> Deepti, what did you mean by "ongoing standardization effort"? Is the >>>>> API shape still being discussed? >>>>> >>>>> On Thu, 2 Apr 2020 at 14:12, Yoav Weiss <[email protected]> wrote: >>>>> >>>>>> I'm wondering if there's something preventing partners from >>>>>> implementing SIMD versions of their applications with the behind-the-flag >>>>>> implementation? >>>>>> >>>>>> I'm assuming you already have some partners lined up for the >>>>>> experiment. Would they be able to develop using the flagged >>>>>> implementation? >>>>>> That would enable us to start the origin trial when they're ready, and >>>>>> as a >>>>>> result, have a shorter trial which purpose is to gather real life usage >>>>>> metrics. >>>>>> >>>>>> On Fri, Mar 27, 2020 at 11:02 PM Deepti Gandluri < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Mounir, >>>>>>> >>>>>>> The reason for a longer trial here is that this proposal is somewhat >>>>>>> large, and while enabling auto-vectorization can give some performance >>>>>>> benefits, to really experiment with this applications may have to >>>>>>> rewrite >>>>>>> their existing code that uses native SIMD intrinsics to use portable >>>>>>> Wasm >>>>>>> intrinsics (example: Emscripten SIMD intrinsics header >>>>>>> <https://github.com/emscripten-core/emscripten/blob/master/system/include/wasm_simd128.h>), >>>>>>> or builtins that map to Wasm operations. >>>>>>> >>>>>>> The intent is to build in enough time for new applications to >>>>>>> experiment with this in parallel to ongoing standardization effort in >>>>>>> the >>>>>>> WebAssembly CG. The ballpark estimate I've used here is from previous >>>>>>> applications experimenting with SIMD, with some buffer to gather data. >>>>>>> That >>>>>>> said, I do understand that this is a longer trial than is usual, so >>>>>>> would >>>>>>> be open to adjusting the timeline based on concerns. >>>>>>> >>>>>>> Thanks, >>>>>>> Deepti >>>>>>> >>>>>>> On Friday, March 27, 2020 at 1:29:09 PM UTC-7, Mounir Lamouri wrote: >>>>>>>> >>>>>>>> Hi Deepti, >>>>>>>> >>>>>>>> This Intent to Experiment looks good, though, I'm wondering why >>>>>>>> this is expected to run for 5 releases, which is roughly 6 months. Is >>>>>>>> there >>>>>>>> something specific we are concerned about and that this timeline aims >>>>>>>> to >>>>>>>> solve? >>>>>>>> >>>>>>>> -- Mounir >>>>>>>> >>>>>>>> On Fri, 27 Mar 2020 at 07:22, Deepti Gandluri <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Contact emails >>>>>>>>> >>>>>>>>> [email protected], [email protected], [email protected] >>>>>>>>> >>>>>>>>> >>>>>>>>> Spec >>>>>>>>> >>>>>>>>> Overview document: >>>>>>>>> https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md >>>>>>>>> >>>>>>>>> Proposal directory: >>>>>>>>> https://github.com/WebAssembly/simd/tree/master/proposals/simd >>>>>>>>> >>>>>>>>> Tag review: https://github.com/w3ctag/design-reviews/issues/487 >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> The WebAssembly SIMD proposal defines a portable, performant >>>>>>>>> subset of SIMD operations that map to vector instructions that are >>>>>>>>> available across most modern hardware platforms. >>>>>>>>> >>>>>>>>> >>>>>>>>> This is purely a WebAssembly performance feature that adds >>>>>>>>> WebAssembly operations and does not affect web API behavior, but is >>>>>>>>> still >>>>>>>>> useful for developers to be aware of as it can change performance >>>>>>>>> characteristics of applications using WebAssembly. >>>>>>>>> >>>>>>>>> >>>>>>>>> Link to “Intent to Prototype” blink-dev discussion: >>>>>>>>> >>>>>>>>> This links to the Intent to Implement discussion for Simd.js >>>>>>>>> <https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Simd.js%7Csort:date/blink-dev/rhPPSQVodq0/zr4HRxXjBgAJ>, >>>>>>>>> which was the basis for the WebAssembly SIMD. The Spec section above >>>>>>>>> has >>>>>>>>> updated links for WebAssembly SIMD, as well as the Tag review. >>>>>>>>> >>>>>>>>> >>>>>>>>> Goals for experimentation >>>>>>>>> >>>>>>>>> Performance: >>>>>>>>> >>>>>>>>> The goal for this experiment is to determine the performance >>>>>>>>> benefit of having WebAssembly SIMD enabled applications in production >>>>>>>>> code, >>>>>>>>> and determine real world performance numbers. We currently have data >>>>>>>>> from >>>>>>>>> isolated benchmarks, and demos, but these do not always reflect real >>>>>>>>> world >>>>>>>>> usage. >>>>>>>>> >>>>>>>>> >>>>>>>>> API Shape: >>>>>>>>> >>>>>>>>> The SIMD proposal currently consists of a set of operations that >>>>>>>>> are well supported across most modern hardware platforms. The set of >>>>>>>>> instructions available on hardware is large and varied, and we are >>>>>>>>> looking >>>>>>>>> for feedback on whether this portable subset is sufficient for a cross >>>>>>>>> section of applications. >>>>>>>>> >>>>>>>>> >>>>>>>>> Experimental timeline >>>>>>>>> >>>>>>>>> M84-M89 >>>>>>>>> >>>>>>>>> >>>>>>>>> Any risks when the experiment finishes? >>>>>>>>> >>>>>>>>> The risk is a drop in performance for sites that were enhancing >>>>>>>>> performance using WebAssembly SIMD operations. >>>>>>>>> >>>>>>>>> >>>>>>>>> Ongoing technical constraints >>>>>>>>> >>>>>>>>> None. >>>>>>>>> >>>>>>>>> >>>>>>>>> Debuggability >>>>>>>>> >>>>>>>>> WebAssembly SIMD needs debugging support in devtools for 128-bit >>>>>>>>> values, as well as baseline compiler support in V8. Both of these >>>>>>>>> efforts >>>>>>>>> are ongoing. (Tracking bugs: crbug.com/v8/10347, crbug.com/v8/9909 >>>>>>>>> ) >>>>>>>>> >>>>>>>>> >>>>>>>>> Will this feature be supported on all five Blink platforms >>>>>>>>> supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and >>>>>>>>> Android)? >>>>>>>>> >>>>>>>>> Yes. >>>>>>>>> >>>>>>>>> >>>>>>>>> Link to entry on the feature dashboard >>>>>>>>> <https://www.chromestatus.com/> >>>>>>>>> >>>>>>>>> https://www.chromestatus.com/feature/6533147810332672 >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 [email protected]. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e4010247-bb4c-47a4-9b82-ea8188c3b232%40chromium.org >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e4010247-bb4c-47a4-9b82-ea8188c3b232%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>>>> 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 [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e9f7ebf3-495e-46b7-82bd-a0f963f1625d%40chromium.org >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e9f7ebf3-495e-46b7-82bd-a0f963f1625d%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEh8BicQHAygqbS0icM4R_%2B9qgzWmOS%2BmqtAicWiqZmRkA%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEh8BicQHAygqbS0icM4R_%2B9qgzWmOS%2BmqtAicWiqZmRkA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/722401d6-1424-47c5-913f-33092ae4b6d0%40chromium.org >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/722401d6-1424-47c5-913f-33092ae4b6d0%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAMi8Y5Updw4FKEp1VQPgdEr9prHtRgYT3Jk90bc%3DMqPW7Q7%3DcQ%40mail.gmail.com.
