Sangwhan: will block out some time, it's a massive spec

Ken: would be nice if people who created babylonjs or threejs to give feedback

Sangwhan: do we have a compute pressure api equivalent for gpus?

Ken: no they don't have that telemetry yet

Sangwhan: risk that a web gpu kernal could choke the gpu to a point where [???]. A WG being chartered

Dan: from process and multi stakeholder perspective this looks good

Sangwhan: disagreement about what to use as shading language seems to have been resolved. SPIR-V and HLSL

Ken: ended up doing their own. Now there's WSL or something. I hope this new one is more webby.

Dan: concerned about fingerprinting and any kind of cross processor vulnerabilities

Sangwhan: a few ways to leak information through webgl, and webgl is a massive fingerprinting surface. This probably opens up more holes. Should this be permission gated? It's incredibly powerful. The memory model part is a concern for me. The fact that gpu memory protection is a bit less .. not as battle tested as cpu memory. Hasn't been abused as much. There are plenty of cases where crappy gpu driver can leak information through the vram

Dan: let's ask these questions

Sangwhan: nothing they can do about it if the gpu driver is bad. In that case should we even do this work, but there's a huge user need / industry need.

Dan: we should be encouraging them to document risks and come up with mitigations

Sangwhan: I think they have a section on this

Dan: S&P review is not talking about fingerprinting at all.

Sangwhan: they do. Also DoS. Thing about memory security.

Dan: don't have specific mitigations

Sangwhan: sort of impossible becausae browser level implementers don't have control over memory controller

Dan: yes and one can find oneself on a webpage that invokes this api by following a malicious link, so it's much easier to get into this situation when you are on the web so just saying it's no different than a native app - people usually make an affirmative choice to install an app, but you don't necessarily have that choice when you're talking about the web, hence safe to brows, blah blah blah. We need to put pressure about mitigations and potentially a permissions step

Sangwhan: permissions definitely something I'd bring up. Mitigations are tricky - drivers are controlled by AMD, nvidia, Intel, ...

Hadley: worth talking to them? Might be the way the industry is going, not just the web.

Sangwhan: a lot of work has been done on the CPU. I'll try to leave feedback. It's tricky. GPU driver stuff is completely proprietary. Different drivers/gpus have different issues. Complexity of the problem increases. I'll draft a comment.

Dan: I might paste in the safe to browse design principle and reinforce this point.

Planning for how to do review so we can schedule it in for next week.

Added Max to issue

Max did some review, will coordinate with other assignees.

Dan: closing comment?

Sangwhan: questions and a closing comment. Will share questions. API design itself looks fine but there should be some safety nets. If you're on a single GPU system you can use any amount of GPU resources on the tab. Something you can do with WebGL but that's a bug not a feature.

.. My comments:

Higher granularity for selecting devices? For example, for cases where one wants to select a high-VRAM device (e.g. for machine learning workloads) or the non-dominant (e.g. secondary device which hopefully will not jank the current compositor) device.
Power consumption - while there is a mechanism to allow applications to request a high power vs low power device, wondering if the choice should be initiated by the user, and not the application
e.g. if the user is on the go, let them choose integrated GPU instead of discrete to save power
Revisiting position on permissions based on this data - and some informal asking around non-technical folks. Graphics is too generic and users will likely be confused - e.g. “yes, I guess the website needs graphics” when it is actually trying to mine Ethereum.
Instead of a permission, should this be something else..?
e.g. big fat warning suggesting “this will use lots of power”
Re: USVString vs DOMString - saw discussion LGTM.

Dan: proposed close?

Sangwhan: yes [will leave comment]

Dan: we are late on this one

Max: a couple of weeks ago Sangwhan and I had a discussion, and had a summary with further questions to ask, but didn't see Sangwhan send the questions. Probably we can discuss in plenary? My suggestion is to send the further questions.

Dan: yes. Do you have the questions? You can post them

Max: we wrote them in a google doc, I can't access it

Dan: let's see if we can get him to post those.. they're waiting. Left a note for Sangwhan.

Max: Sangwhan had questions, hasn't put them on github yet. Had a discussion and he summarised further questions to ask

Amy: did he put them in slack?

Max: ah yeah.. about the hierarchy of selecting devices and power consumption concerns and information ..

Amy: you can post them?

Max: we can wait for Sangwhan.. I'll remind

Sangwhan: [appears] I will do that