Skip to content

Minutes 2021 02 01

Jump to bottom
Corentin Wallez edited this page Feb 5, 2021 · 1 revision

GPU Web 2021-02-01

Chair: Corentin

Scribe: Ken / Jeff / Corentin

Location: Google Meet

Tentative agenda

  • Administrivia
    • Next F2F
  • PR burndown
    • Require [SecureContext] for using WebGPU. #1363
    • Rename GPUVertexFormat members to match GPUTextureFormat #1322
    • Change [Buffer/Texture/ImageBitmap]CopyView to CopyLocation #1375
  • Development-only API features #814
  • Require storeOp when resolveTarget is specified? #1376
  • Reconsider GPULoadOp "clear"/"zero" #1377
  • Agenda for next meeting

Attendance

  • Apple
    • Dean Jackson
    • Myles C. Maxfield
    • Devin Rousso
  • Google
    • Austin Eng
    • Brandon Jones
    • Corentin Wallez
    • Kai Ninomiya
    • Ken Russell
    • Shrek Shao
  • Intel
    • Yunchao He
  • Microsoft
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Andrew Varga
  • Jack Osborn
  • Philip Barker
  • Michael Shannon
  • Mehmet Oguz Derin
  • Timo de Kort

Administrivia

  • Next F2F
    • Constraints from WGSL participants?
    • 2 weeks leeway - week of Feb 15? or the 22nd?
    • Jeff Gilbert suggested https://www.when2meet.com/ rather than Doodle polls
    • MM: for discussion of developer-only APIs, a member of our DevTools team would like to join
      • CW: we’ll click “accept” for the person who wants to join

PR burndown

  • Require [SecureContext] for using WebGPU. #1363
    • JG: Recommendation from standards discussion inside Mozilla about what Mozilla wants from the API. All new APIs should be behind secure context. It basically means this is an HTTPS only API. There's an explainer linked in the issue.
    • MM: understand the “what” - what about the “why”?
    • JG: one historical reason - get people moving onto HTTPS. Little less of a concern now. Other reason - we feel better from a defense-in-depth perspective. If bugs in it, nice if we only have to care about attack vectors from place user is trying to go to, aside from person using HTTP and a MITM attack happens, abuses us while we’re trying to get security out the door.
    • MM: isn’t this true of every web API? Why is this unique to WebGU?
    • JG: it is true of every API. This is why Mozilla is pushing for [SecureContext] fr new APIs.
    • CW: we hear the same feedback from our security folks. WebGPU’s more on the “scary” side - let you run arbitrary code on a piece of hardware. If were just CSS property, not [SecureContext] - also web APIs that stay entirely inside the sandboxed process. More scary APIs should be [SecureContext].
    • DJ: I get the idea, but think it shouldn’t be in the spec. It’s not WebGPU’s issue. Maybe in the HTML spec, or some other thing.
    • KN: this is the direction many other specs have gone. Does APple have a position on those?
    • DJ: yes, Apple’s on the side of not spec’ing SecureContext. Shouldn’t be an API specific topic but higher up in the HTML spec. If a coalition of browsers, etc., decide that all APIs should be SecureContext, we can go in that direction.
    • JG: it’s my management / leadership pushing for this. Positive that when we go for TAG review they’ll care. It’s on us to try. If you could contact the experts on your side and get a read from them, that may be the easiest path forward.
    • DJ: I’m pretty much representing what they want. TAG shouldn’t say, here are the APIs that need to be SecureContext only; all APIs should say this in some form.
    • JG: Web IDL might be a little behind in this. Default recommendation from Mozilla, default should be [SecureContext]. If Web IDL were updated to take all vendors’ considerations, probably would be securecontext by default.
    • MM: don’t think Apple would agree with that position.
    • CW: TAG says you should consider SecureContext, but that some people believe one thing, and others another.
    • DJ: As Jeff said, [SecureContext] was originally intended to push people toward HTTPS. I can’t think of major security issues where web APIs were HTTP-only.
    • JG: I’m saying it’s a big deal for Mozilla.
    • CW: similar discussions with SharedArrayBuffer, COOP and COEP.
    • MM: Let's assume we all agree that WebGPU because of security really needs this [SecureCOntext] thing. Thumbs up. IF fundamental property of API that this restriction is necessary. There are … from this group or other groups where this isn’t true. They’ve proposed some rendering thing, and HTTPS only - the reason was just that they wanted people to use HTTPS. That’s where we’ve pushed back historically. Justification needs to be stronger. Make the case more than just “this is scary” that this API needs to be SecureContext.
    • CW: people or the network injecting Ethereum miners on your requests, instead of just the origin you’re going to . You use a captive portal, and every HTTP page you visit will be mining WebGPU.
    • MM: isn’t that true of regular JS?
    • JG: different - more efficient with WebGPU, more attractive, will be exploited.
    • CW: also what about portability of some browsers requiring HTTPS, and some not?
    • MM: would be fine with us.
    • CW: that’s scary, a portability hazard.
    • JG: can go back & get more details from my mgmt, but this was coming down from the top-level. We have a repo on Github about how Mozilla handles these APIs. We’ve mostly handled the concerns about WebGPU’s position - this is the last one my mgmt has told me.
    • DJ: I agree - think a TAG notice saying “you should consider” is weird. We don’t know what to consider. Would be better if the W3C said “you should just do this” and then I’d be totally happy.
    • MM: many of us have been speaking on behalf of our companies - why don’t we take a week and come back to it.
    • JG: another way we can make progress - this is one of the many things awaiting TAG review. We can ask them whether they’ll insist on [SecureContext] and if they say yes.
    • DJ: we should also ask them to stop saying “you should consider” and say “you should”.
    • CW: everyone, go back and ask your web standards folks about reasons for/not [SecureContext].
    • MM: would be nice if the TAG laid out the criteria for [SecureContext].
    • KN: think if there were such a list of criteria, WebGPU would match this.

Development-only API features #814

  • CW: there are some features of the API that we probably don’t want to expose to every website, like timestamp queries - too fine-grained measurement of what’s going on. These are not super useful if they’re quantized. They’re useful for developers while making their WebGPU app. An idea surfaced multiple times - features could be exposed only under certain circumstances. Maybe DevTools checkbox, I’m in WebGPU developer mode - or browser flag, or something else. Ideas?
  • MM: we’re fairly negative on this proposal for a variety of reasons. Most straightforward: we try to make it hard to know when the web inspector is open. Many checkboxes are sticky in the inspector, so they indicate when it’s open.
  • DR: (Devin Rousso) more elaboration: we make these sticky b/c DevTools is supposed to be developer-friendly - would be user-hostile to have to recheck box every time. This is perhaps the first time something would be exposed by the web inspector. I’ve seen a couple dozen websites that shut themselves down if they detect web inspector. debugger statement is one of these. They do performance.now before and after debugger; statement. Apple’s Web Inspector added a feature to disable that statement. You open up the possibility that web APIs will use them adversarially.
  • CW: so it’s another vector to discover Web Inspector is open.
  • DR: in isolation, whether a page knows Web Inspector is open isn’t that bad - it’s what they do with that information. one page I saw with this - WSJ. If you were using Web Inspector, they’d throw up a big dialog, don’t open Web Inspector. Very hostile behavior. Also web devs trying to use WSJ to learn how to do this.
  • MS: third use case. If you can block the web inspector you block security researchers too.
  • MM: yes. Could imagine “if (web-inspector-exposed thing) { … } else { … }”. Code inside “else” is un-debuggable.
  • CW: think it’s clear that the inspector being open should not be discoverable. In the proposals we’ve made, timestamp queries being exposed is something the developer does themselves. Problem of sticky checkboxes - you won’t do it by happenstance though. I’m not a UX designer but what about making the checkbox sticky per origin?
  • MM: our position isn’t that there shouldn’t be a web inspector feature - it’s that it shouldn’t be discoverable by the page.
  • CW: that’s a more general statement - we don’t want this WI feature to be detected & used by attackers.
  • DR: in the situation you’re debugging your own website - wouldn’t care whether the WI’s open. Problem’s when you’re debugging someone else’s website. Security / performance researcher. You might intentionally click this checkbox to get more information about the site, and it would forbid that. Console things - always return undefined. Undetectable. Have no objection to console.blah or a property to put it in the console.
  • JG: we understand that it can be complicated to get this right in a way that continues our current guarantees. Researchers / developers can both do their jobs. What about - only one aspect here that’s behavior-modifying when you enable it. If you're a security researcher, hoping to use that to learn more about the page, page says no - nothing you can do about that in general. We’re not proposing that you only get all of the debugging possibilities of webgpu if you have this observable one. It’s more about turning on the cooperative debugging mechanisms for WebGPU. THere are other aspects that aren’t cooperative. Interact with DevTools transparently, the website never knows. These are two different things. Complications of one doesn’t have to preclude the ability of the other to exist.
  • DR: can you give an example if the page says “no”, you can’t do this with the WI, you have no recourse? In our opinion the WI is a layer underneath the page.
  • KR: These are cooperative mechanisms. Page inherently has to be modified to show the results of these queries.
  • JG: I’ve written things to parse console output, had to be cooperative. I understand the desire to do as much as possible in a transparent way / content-agnostic - but some of the things aren’t agnostic. Require some cooperation by the browser (application?). Worst-case scenario - you load up the developer console, looking at an app - you have no indication the app has this cooperative timestamp mechanism, you enable it, the app rejects you and shuts you out. Can do other sanity checks in the app to make sure nobody’s messing around. There are a bunch of things we’d like to include in WI that would do this. We’re saying, what if we can enable something that turns on an optional feature?
  • MM: in this issue, there’s a list of several items. If I understand correctly, think we’re only talking about the first 2 items? 4th one, browsers don’t need to standardize? Content of error messages isn’t standardization material.
  • CW: probably 4th one eventually.
  • MM: does that need to be standardized?
  • KN: think we can just do breakpoints instead.
  • MM: there are timers already in JS. Having a function, “please time this”, isn’t unreasonable.
  • BJ: a lot of this discussion has been centered around devtools & exposing things to pages. Looking back in WebGL, one reason Chrome pushed to expose context debugging all the time was from Maps & game engines - wanted to correlate performance problems with various GPUs in the wild. Sending out things to every web-capable machine in the world. Devs might say, I want to submit a bug report, click this button, collect data, would want to do some timing, how long does this shader take. On your particular system, this compute shader is the bottleneck and it wasn’t on mine. Devs will want those statistics. Agree we shouldn’t blast out highest fidelity timing forever - but enabling it in DevTools would eliminate the ability to do this kind of debugging support. “In this browser, click this thing, this tab, this checkbox” - awful. We don’t want to do that. What to do? Start up a new context with the feature? There are more cases out there than the developer just testing on my machine.
  • MS: we recently did something similar with a desktop OpenGL application. It does happen.
  • MM: I think this idea that there are already timing facilities but we’re not defining the fidelity sort of solves the problem. Can have WI-specific functionality, when the page asked how long it took: it took X time, but in WI it really took Y time. I can implement that no problem. Doesn't need to be in the spec though.
  • BJ: to clarify - you’d get a quantized number through the API, but higher fidelity in console?
  • MM: imagining function in WI, input would be an object in the regular WebGPU API, output would be a result that’s higher fidelity than the one exposed to the page. Browsers would know to call that function and get higher fidelity.
  • DR: to elaborate more - could have a situation where when you run the function that gives you back the timing, we log the real time in WI. There are several functions exposed through the console command line API - example, can crawl the entire JS heap for all instances that inherit from a prototype. Just gives you an array of everything. We already have console.record - primarily for 2D/WebGL debugging. Could give it a command buffer, console.record this - that’s exposed to the page, just doesn’t do anything in the context of the page. Data’s entirely in the context of the WI.
  • DM: what Brandon explained - you can already achieve this with command buffer timing we already have. Do the same operation 1M times, get the same precision. My point - cooperation can be one-way. Non-observable. Query resolve can happen to be non-observable host-side. Resolve pipeline statistic query. Peek into the resolve result, do something about it. As long as it’s not observable by a page, same guarantee as console.println.
  • MM: step in the right direction. Could go farther. Query resolution does return the result to the page, it’s just quantized.
  • CW: I have strong concerns - requires building whole WebGPU debugger in the DevTools. Technically doable, but huge amount of work. Not sure any browser will do this. Unfortunate to gate devs being able to use the data from timing / pipeline statistics queries on gathering a LOT of additional data in the WebGPU impl. It’s pretty insane to build this.
  • MM: having hard time understanding what “this” is. Thought we were only talking about first 2 points in the post?
  • CW: you need to knwo where in the cmdbuf the timestamp queries were recorded. Record / resolve operations have to be linked to push/pop debug markers. Gets extremely complicated really really fast.
  • DR: in this situation aren’t we imagining that the dev’s doing this debugging? They’d already know where they want to add these things. If we added this to a console function, or we quantize it from an existing function, --- these are no-ops when WI doesn’t exist. They can build them into their page, use them, and leave them there.
  • JG: think this is a Gordian knot, can’t we cut it? Hard for us to reach consensus that all of our UAs want to do this. If we can have something that some of our UAs expose as optional in the spec - like we have for WebGL - and have prefs for e.g. high-precision timers, then can postpone more discussion about convincing all UAs to do the same thing.
  • MM: if we want to limit this to something DevTools just do, and they happen to agree - we want to have control over the development and DevTools experience. Build things as we go. If we say, here’s this feature and you have to implement all of it, doesn’t give us (the WebKit team) the flexibility we want with our DevTools. Can’t be “implement this thing”, but here are 100 options and the browser chooses the appropriate things for its audience.
  • CW: what about timestamp and pipeline statistics queries? We have appetite for this. If not all UAs implement this - do we move it to a separate document?
  • MM: we do want to implement these - just in a non-fingerprintable way. Want to quantize the results. Should have the functions. The spec shouldn’t guarantee what the precision is. If you want higher precision, that’s a DevTools feature.
  • JG: OK. Then just need to decide the form if we standardize them. High-precision timers, wouldn’t have to standardize. Just UA decides the precision.
  • MM: just need to spec it in a way that browser can inject a compute shader to quantize.
  • CW: or say “no, you don’t have this functionality”. If you’re really untrusted maybe we wouldn’t give you the timing info.
  • MM: would be OK. WebKit wouldn’t do this probably.
  • JG: sounds like that solves timers.
  • MM: I don’t know enough about pipeline statistics and whether they can be quantized.
  • JG: is a palatable way to standardize this - similar to how OpenGL standardized the timestamp bits? Have a queryable number of bits, and can be as low as 0? Is that a path where we can agree on the form it takes?
  • MM: philosophy sounds fine. Number of bits we probably wouldn’t want to expose. If you’re a device that can’t give a number, reporting 0 in a scalar field is a bad design choice. We have extensions, so should be an extension.
  • JG: great.
  • CW: OK.
  • DR: thanks for taking the time and rescheduling.
  • CW: sounds like we have consensus on this being optional feature, browsers can quantize, browsers can choose mechanism for exposing higher precision.
  • MM: APIs need to be designed so that we can inject compute shader. Also has to be expectation, reasonable for browsers to usually encode this compute shader. We’re probably going to do it every time we resolve a timestamp. In the future, we should be under the assumption that these little compute shaders will be injected, and that’s not unreasonable for a browser to do.
  • JG: would it feel better to have non-normative text in the spec document? “It’s likely that browsers will inject compute shaders…”
  • MM: better - normative text “the precision of this value is undefined.”
  • CW: when designing things that interact with these features, have to assume compute shader upon resolve.
  • MM: yes.

Agenda for next meeting

  • DM: replaced by WGSL meeting?
  • CW: think that would work.
  • KN: we could, but think we do have stuff to discuss.
  • MM: think it’s worth discussing GPU vertex formats.
  • CW: in a meeting?
  • MM: yes. You can veto.
  • CW: this one, should try to resolve offline. If don’t, then discuss.
  • KN: majorPerformanceCaveat, want to discuss removing (...?) and limits.
  • MM: all of our WGSL stuff is there now.
  • CW: let’s have an API meeting next week then. Will have proposal for “fat video samplers” - which we may or may not want for V1. This is in order to do 0-copy YUV sampling, but without telling the app what it is. Hopefully with that and Shaobo’s WebCodecs stuff we can fill the rest of the meeting.
  • KN: think we have plenty.
Clone this wiki locally