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