IRC log of webgpu on 2019-09-18

Timestamps are in UTC.

01:46:32 [RRSAgent]
RRSAgent has joined #webgpu
01:46:32 [RRSAgent]
logging to https://www.w3.org/2019/09/18-webgpu-irc
01:46:35 [koalie]
RRSAgent, make logs public
01:46:37 [koalie]
koalie has changed the topic to: https://w3c.github.io/tpac-breakouts/sessions.html
01:46:41 [koalie]
koalie has left #webgpu
02:06:13 [myles]
myles has joined #webgpu
04:33:09 [myles]
myles has joined #webgpu
05:29:56 [myles]
myles has joined #webgpu
06:38:15 [myles]
myles has joined #webgpu
07:10:37 [myles]
myles has joined #webgpu
07:11:29 [myles]
myles has joined #webgpu
07:31:07 [myles]
myles has joined #webgpu
08:30:53 [myles]
myles has joined #webgpu
08:32:21 [tidoust]
tidoust has joined #webgpu
08:32:51 [mdrimages]
mdrimages has joined #webgpu
08:33:17 [dino]
dino has joined #webgpu
08:33:26 [dino]
scribenick: dino
08:35:30 [tk]
tk has joined #webgpu
08:36:09 [jbroman]
jbroman has joined #webgpu
08:36:14 [Mek]
Mek has joined #webgpu
08:36:29 [suzuki]
suzuki has joined #webgpu
08:36:35 [dino]
Myles: Hi I'm Myles Maxfield. Work for Apple on the WebKit team.
08:36:43 [MikeSmith]
MikeSmith has joined #webgpu
08:36:47 [niwamoto]
niwamoto has joined #webgpu
08:36:51 [stantonm]
stantonm has joined #webgpu
08:36:56 [dino]
myles: our clear goals are -
08:37:01 [dino]
1. high level background
08:37:03 [michael_li]
michael_li has joined #webgpu
08:37:05 [dino]
2. get feedback
08:37:32 [dino]
WebGPU is a CG. Goal is for developers to be able to use the system's GPU as much as possible, and all the benefits of that.
08:38:02 [dino]
Why not WebGL? Trend is that over the past 5 years there are new graphics APIs that have a very different design compared to OpenGL.
08:38:03 [dbaron]
dbaron has joined #webgpu
08:38:24 [dino]
OpenGL has a long history, and the current API doesn't map very well to modern hardware.
08:39:00 [ak]
ak has joined #webgpu
08:39:10 [dino]
These new APIs, while different, share common design principles. And so the goal of WebGPU is to have a new API that can work on each of these lower-level APIs.
08:39:24 [dino]
And it also exposes compute functionality to the Web.
08:39:42 [dino]
3 APIS are Metal (Apple), D3D12 (Microsoft) and Vulkan (Khronos)
08:40:28 [Zhiqiang]
Zhiqiang has joined #webgpu
08:40:31 [dino]
Because we're exposing hardware features, we have to be very careful with design. Top priority is security - we need to ensure that a page can't access things it was not intended to.
08:41:01 [dino]
This is fairly easy on CPUs, but it is much harder to guarantee on GPUs. So it must be something we design in from the start.
08:41:43 [dino]
Next is interoperabilty. Not only are the APIs different, there is a wide range of hardware out there. So we want something that will work acceptably well everywhere.
08:42:42 [dino]
The next is performance. There is actually nothing you can do in WebGL/WebGPU that you can't do with JavaScript. However, with things like 3d graphics, they can be done many many times faster on a GPU.
08:43:13 [jeff_]
jeff_ has joined #webgpu
08:43:21 [jeff_]
present+ jeff
08:43:41 [dino]
myles: (shows a demo of a babylon.js model that works in Safari + Chrome with WebGPU turned on)
08:44:19 [dino]
question: what GPU is this demo using?
08:44:25 [dino]
myles: this is the integrated Intel GPU
08:44:35 [dino]
question: what about performance compared to WebGL?
08:45:23 [dino]
myles: we wrote a basic benchmark to measure this. Our results show that WebGPU is between 2x and 8x "faster" than WebGL.
08:45:39 [dino]
myles: what's interesting in our benchmarks is that we are now mostly bound by the GPU, not the CPU.
08:46:00 [dino]
myles: so why are we getting better performance compared to WebGL?
08:46:29 [dino]
- shows coloured cube. explains vertex data.
08:46:44 [dino]
myles: the way you would do this in WebGL is to describe the state on each draw call.
08:47:23 [dino]
myles: in WebGPU you can create a "pipeline" up front, and reuse it during drawing. This means the programmer has control over when the validation happens, and also there are fewer calls between JS and C++
08:48:06 [dino]
myles: similarly for binding - in WebGL you have to bind all the textures each draw. In WebGPU you can save the collection of bindings.
08:48:15 [dino]
mike: what do you mean my validation?
08:49:36 [dino]
myles: when you create these batch objects, we are calling directly into the hardware and referencing an opaque thing.
08:49:50 [dino]
myles: talk about the future of the group.
08:50:03 [dino]
(shows an image of a checkered flag)
08:50:22 [kip]
kip has joined #webgpu
08:50:26 [dino]
notice that it isn't just black and white, there are ripples, and reflections, and bloom and highlights
08:50:48 [dino]
this is done by a program that runs to work out the output of each pixel
08:50:55 [dino]
these are called shaders
08:52:11 [dbaron]
SPIR-V versus Web High-Level Shading Language (WHLSL) ??
08:52:14 [dino]
myles: there are two proposals: SPIR-V is binary format that comes from Khronos. WSL is a text format that is owned by the CG. Each have pros and cons.
08:52:42 [dino]
This is the next big decision that the group needs to make - which shading language should we use?
08:52:51 [dino]
https://github.com/gpuweb/
08:53:01 [dino]
Specification at https://gpuweb.io/
08:53:26 [Judy]
Judy has joined #webgpu
08:53:26 [jbroman]
https://webgpu.io/ ?
08:53:33 [dino]
yeah sorry
08:53:40 [Judy]
present+ Judy
08:53:53 [dino]
???: About performance. You mentioned a microbenchmark. Do you have any data on real world applications?
08:54:01 [sangwhan]
q+
08:54:09 [dino]
myles: not yet, because there isn't much real world content. we're working on it.
08:54:11 [dino]
q?
08:54:32 [dino]
myles: we could port an existing benchmark
08:54:35 [dino]
ack sangwhan
08:54:42 [Zakim]
Zakim has joined #webgpu
08:54:52 [dino]
sangwhan: you mentioned multiple languages. when do you think that will be resolved?
08:54:55 [ningxin_hu]
ningxin_hu has joined #webgpu
08:54:57 [majidvp]
majidvp has joined #webgpu
08:55:22 [dino]
myles: we have a meeting next week. Hopefully we can work it out.
08:55:41 [dino]
sangwhan: there is a TAG process for helping to resolve issues like this.
08:56:01 [dino]
???: are you going to develop a shader compiler?
08:56:20 [sangwhan]
s/???/narufumi/
08:56:27 [kip]
q+ To say I would like to know if a WASM wrapper story has been explored. (eg, something like MoltenVK + WASM + WebGPU). Would one shader language be easier to transcode to than others?
08:56:50 [dino]
myles: multiple pieces to the answer. The CG wouldn't make a compiler. It would make a spec. The implementation would make a compiler. That would be done in open source.
08:57:05 [dino]
myles: for example, the SPIR-V compiler is a separate project.
08:57:12 [sangwhan]
q+ to ask how shaders will be shipped around
08:58:55 [dino]
myles: none of those 3 APIs have shading languages that meet the security restrictions of the Web. So we *must* accept a language, do some kind of validation and rewriting to produce the system language.
08:58:58 [dino]
q?
08:59:26 [dino]
myles: we are hoping that the overhead of Web -> platform is only 10% more than native -> platform
09:00:15 [dino]
kip: WASM story. Do you have a story about how to port native apps e.g. a MoltenVK type of system that wraps WebGPU
09:00:41 [dino]
myles: there isn't a final answer yet on how to expose WebGPU to WASM. We are interested but just not ready.
09:01:42 [Zakim]
kip, you wanted to say I would like to know if a WASM wrapper story has been explored. (eg, something like MoltenVK + WASM + WebGPU). Would one shader language be easier to
09:01:45 [Zakim]
... transcode to than others?
09:01:58 [dino]
myles: when we talked to developers who have experience with WebGL they said they are fine with a JS API for now.
09:02:20 [dino]
myles: we will choose the web when there is a conflict on API design
09:02:26 [dino]
ack sangwhan
09:02:26 [Zakim]
sangwhan, you wanted to ask how shaders will be shipped around
09:02:37 [dino]
sangwhan: how are shaders delivered nowadays?
09:02:47 [niwamoto]
ack Iwamoto
09:02:50 [dino]
myles: SPIR-V is a byte code. WSL is a text language.
09:02:57 [dino]
sangwhan: does it run on the main thread?
09:03:38 [Judy]
rrsagent, draft minutes
09:03:38 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/18-webgpu-minutes.html Judy
09:03:57 [dino]
myles: great question! when we got feedback on WebGL, the main complaint was that compilation of shaders was a pain point. So WebGPU always does non-main thread compilation. We're also working on how to get the API usable across workers.
09:04:08 [kimwooglae]
kimwooglae has joined #webgpu
09:04:21 [dino]
ningxin_hu: we also have to consider threadgroup read. did you cover that area?
09:05:02 [dino]
ningxin_hu: some kind of API in WebGPU for threaded reads?
09:05:11 [idcc]
idcc has joined #webgpu
09:05:39 [dino]
myles: yes, matching the lower level APIs. In order to get good performance the developer has to pick a threadgroup size, and this is a difficult thing to decide. We're investigating.
09:06:26 [dino]
ningxin_hu: sometimes the hardware vendors are much faster to innovate on features. how will the WebGPU API keep up?
09:07:23 [dino]
myles: we'll always be on top of the core APIs. We can only expose what they expose.
09:07:23 [dino]
present+
09:07:42 [Judy]
Chair: Myles Maxfield
09:08:35 [dino]
myles: we only add an extension if it exists on multiple bits of hardware
09:08:46 [Judy]
Meeting: TPAC 2019 breakout session on WebGPU
09:08:52 [dino]
Michael Li: What does non-graphics computation look like?
09:08:59 [dino]
e.g. machine learning
09:09:26 [dino]
myles: the easy answer is that it looks a lot like all these APIs work - you have a grid of threads that work on buffers of data.
09:09:48 [dino]
myles: and it is pretty easy for us to map the programming model for the platform APIs onto WebGPU.
09:10:46 [dino]
???: There are some devices that are compute-only. Could they be supported by WebGPU?
09:10:58 [dino]
dino
09:11:23 [dino]
dino: are you talking about ML hardware?
09:11:23 [dino]
???: yes
09:11:23 [dino]
myles: we haven't discussed it
09:11:30 [dino]
myles: please open an issue on WebGPU about that.
09:12:49 [Judy]
dino: It might be difficult to find a base set of features that we could expose everywhere
09:14:01 [Judy]
...if possible get a device that only does generic computer cause that's what you need
09:14:16 [Judy]
...and you can expose new operations...
09:14:20 [dino]
???: feature detection might work. similar to the way you select low power and high power.
09:14:25 [dino]
---- end ----
09:14:31 [dino]
RRSAgent, make minutes
09:14:31 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/18-webgpu-minutes.html dino
09:50:15 [dbaron]
dbaron has left #webgpu
11:55:32 [tidoust]
tidoust has joined #webgpu
13:19:09 [Zakim]
Zakim has left #webgpu
13:51:46 [Judy]
Judy has joined #webgpu
16:17:46 [Judy]
Judy has joined #webgpu