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
<https://github.com/gpuweb/gpuweb/issues/614>
Specification
https://gpuweb.github.io/gpuweb/#timestamp
<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.
--
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/6a4087db-222c-48a8-8dfd-7139c8c9e723%40chromium.org.
