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.

Reply via email to