LGTM3 On Wed, Nov 8, 2023 at 7:38 AM Daniel Bratell <bratel...@gmail.com> wrote:
> LGTM2 > > 100 microseconds sound very coarse for this, but I guess that just means > they have to average data over many frames. And if they are happy, I'm > happy. > > /Daniel > On 2023-11-08 09:41, Yoav Weiss wrote: > > LGTM1 > > Thanks for working through this issue!! > > On Wed, Nov 8, 2023 at 2:34 AM Domenic Denicola <dome...@chromium.org> > wrote: > >> >> >> On Tue, Nov 7, 2023 at 5:42 PM François Beaufort <fbeauf...@google.com> >> wrote: >> >>> >>> >>> On Mon, Oct 30, 2023 at 7:39 PM Mike Taylor <miketa...@chromium.org> >>> wrote: >>> >>>> On 10/30/23 12:59 PM, Corentin Wallez wrote: >>>> >>>> On Fri, Oct 27, 2023 at 2:19 AM Domenic Denicola <dome...@chromium.org> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Oct 26, 2023 at 7:21 PM François Beaufort < >>>>> fbeauf...@google.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 26, 2023 at 11:05 AM Domenic Denicola < >>>>>> dome...@chromium.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 26, 2023 at 5:21 PM 'François Beaufort' via blink-dev < >>>>>>> blink-dev@chromium.org> wrote: >>>>>>> >>>>>>>> Contact emails >>>>>>>> >>>>>>>> fbeauf...@google.com, cwal...@google.com >>>>>>>> >>>>>>>> Explainer >>>>>>>> >>>>>>>> https://github.com/gpuweb/gpuweb/issues/614 >>>>>>>> >>>>>>>> Specification >>>>>>>> >>>>>>>> https://gpuweb.github.io/gpuweb/#timestamp >>>>>>>> >>>>>>>> Summary >>>>>>>> >>>>>>>> WebGPU timestamp queries allow WebGPU applications to measure >>>>>>>> precisely (down to the nanosecond) how much time their GPU commands >>>>>>>> take to >>>>>>>> execute, especially at the beginning and end of passes. Timestamp >>>>>>>> queries >>>>>>>> are heavily used to gain insights into the performance and behavior of >>>>>>>> GPU >>>>>>>> workloads. >>>>>>>> >>>>>>>> While the WebGPU specification makes timestamp queries an optional >>>>>>>> feature due to timing attack concerns, we believe that timestamp >>>>>>>> queries >>>>>>>> quantization provides a good middle ground by reducing the precision of >>>>>>>> timers. To offer even more advanced protection against timing attacks >>>>>>>> and >>>>>>>> fingerprinting, timestamp queries are also coarsened based on site >>>>>>>> isolation status: >>>>>>>> >>>>>>>> - Isolated contexts: timestamp queries are exposed with a >>>>>>>> resolution of 100 microseconds. >>>>>>>> >>>>>>>> - Non-isolated contexts: timestamp queries are not exposed at all. >>>>>>>> >>>>>>> >>>>>>> By "isolated" do you mean "has the cross-origin isolated capability >>>>>>> <https://html.spec.whatwg.org/#concept-settings-object-cross-origin-isolated-capability> >>>>>>> "? >>>>>>> >>>>>> >>>>>> Yes. >>>>>> >>>>>> >>>>>>> >>>>>>> I wasn't able to find any spec or tests for this requirement, which >>>>>>> seems like a potential interoperability issue. >>>>>>> >>>>>> >>>>>> The WebGPU spec currently says: "The feature is optional, and a >>>>>> WebGPU implementation may limit its exposure only to those scenarios that >>>>>> are trusted." >>>>>> See >>>>>> https://gpuweb.github.io/gpuweb/#security-timing:~:text=The%20feature%20is%20optional%2C%20and%20a%20WebGPU%20implementation%20may%20limit%20its%20exposure%20only%20to%20those%20scenarios%20that%20are%20trusted >>>>>> >>>>> >>>>> I realize that. I was suggesting that, for interoperability purposes, >>>>> you should consider specifying the actual condition, instead of leaving it >>>>> vague and optional. (E.g. at least in other standards bodies, we have >>>>> guidance to avoid optional or implementation-defined features; instead, we >>>>> try to work together with other browser engines to come to a common, >>>>> interoperable implementation, backed by a test suite.) >>>>> >>>>> I hope the API Owners can consider this when deciding whether or not >>>>> to approve, as I believe that letting these sorts of non-specified and >>>>> non-tested features be shipped is harmful for the platform's health. >>>>> >>>>> >>>> I'll add discussion of that to the agenda for this week's WebGPU >>>> meeting: can we agree on the availability of timestamp queries (provided >>>> there is hardware support) and the quantization depending on contexts. (but >>>> to be perfectly honest I think we'll have pushback). Of course the WebGPU >>>> standard body tries to avoid implementation-defined features, and instead >>>> have deterministic and tested features, but timestamps is one of the ones >>>> that might need to be an exception to it. Let's see what consensus the >>>> group comes to! >>>> >>>> >>>> Thank you - looking forward to the update. >>>> >>> >>> Good news! The members of the GPU for the Web Community Group have accepted >>> a proposal >>> <https://github.com/gpuweb/gpuweb/issues/4175#issuecomment-1789865938> >>> to allow timestamps regardless of site isolation, always with the >>> non-isolated resolution from hr-time >>> <https://w3c.github.io/hr-time/#dfn-coarsen-time> (100us). >>> Check out the spec PR at https://github.com/gpuweb/gpuweb/pull/4359 and >>> updated spec at https://gpuweb.github.io/gpuweb/#security-timing. This >>> decision aims to address the interoperability concerns raised earlier. >>> >> >> That's great! Using the same time resolution as the rest of the platform >> makes sense, and this definitely addresses my interop concerns. Thanks to >> you and the group for making this change! >> >> -- >> 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/CAM0wra_p2U%2BwqkMrhH12DgMzph_77Ps4xk0Bn_ZspD%2BWEYzuqA%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_p2U%2BwqkMrhH12DgMzph_77Ps4xk0Bn_ZspD%2BWEYzuqA%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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUuxbMGbLHiKmhCttPF3H4c23NkvCjMu7dY_Ok8NDQkxw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUuxbMGbLHiKmhCttPF3H4c23NkvCjMu7dY_Ok8NDQkxw%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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4b86877b-ca04-464d-85df-2b4ce479194a%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4b86877b-ca04-464d-85df-2b4ce479194a%40gmail.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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-rWkiJD3H8PXAXTFUZoTD%3D%3DSSwBOzyxL0jS7NMezrxKw%40mail.gmail.com.
