01:46:32 RRSAgent has joined #webgpu 01:46:32 logging to https://www.w3.org/2019/09/18-webgpu-irc 01:46:35 RRSAgent, make logs public 01:46:37 koalie has changed the topic to: https://w3c.github.io/tpac-breakouts/sessions.html 01:46:41 koalie has left #webgpu 02:06:13 myles has joined #webgpu 04:33:09 myles has joined #webgpu 05:29:56 myles has joined #webgpu 06:38:15 myles has joined #webgpu 07:10:37 myles has joined #webgpu 07:11:29 myles has joined #webgpu 07:31:07 myles has joined #webgpu 08:30:53 myles has joined #webgpu 08:32:21 tidoust has joined #webgpu 08:32:51 mdrimages has joined #webgpu 08:33:17 dino has joined #webgpu 08:33:26 scribenick: dino 08:35:30 tk has joined #webgpu 08:36:09 jbroman has joined #webgpu 08:36:14 Mek has joined #webgpu 08:36:29 suzuki has joined #webgpu 08:36:35 Myles: Hi I'm Myles Maxfield. Work for Apple on the WebKit team. 08:36:43 MikeSmith has joined #webgpu 08:36:47 niwamoto has joined #webgpu 08:36:51 stantonm has joined #webgpu 08:36:56 myles: our clear goals are - 08:37:01 1. high level background 08:37:03 michael_li has joined #webgpu 08:37:05 2. get feedback 08:37:32 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 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 has joined #webgpu 08:38:24 OpenGL has a long history, and the current API doesn't map very well to modern hardware. 08:39:00 ak has joined #webgpu 08:39:10 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 And it also exposes compute functionality to the Web. 08:39:42 3 APIS are Metal (Apple), D3D12 (Microsoft) and Vulkan (Khronos) 08:40:28 Zhiqiang has joined #webgpu 08:40:31 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 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 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 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_ has joined #webgpu 08:43:21 present+ jeff 08:43:41 myles: (shows a demo of a babylon.js model that works in Safari + Chrome with WebGPU turned on) 08:44:19 question: what GPU is this demo using? 08:44:25 myles: this is the integrated Intel GPU 08:44:35 question: what about performance compared to WebGL? 08:45:23 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 myles: what's interesting in our benchmarks is that we are now mostly bound by the GPU, not the CPU. 08:46:00 myles: so why are we getting better performance compared to WebGL? 08:46:29 - shows coloured cube. explains vertex data. 08:46:44 myles: the way you would do this in WebGL is to describe the state on each draw call. 08:47:23 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 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 mike: what do you mean my validation? 08:49:36 myles: when you create these batch objects, we are calling directly into the hardware and referencing an opaque thing. 08:49:50 myles: talk about the future of the group. 08:50:03 (shows an image of a checkered flag) 08:50:22 kip has joined #webgpu 08:50:26 notice that it isn't just black and white, there are ripples, and reflections, and bloom and highlights 08:50:48 this is done by a program that runs to work out the output of each pixel 08:50:55 these are called shaders 08:52:11 SPIR-V versus Web High-Level Shading Language (WHLSL) ?? 08:52:14 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 This is the next big decision that the group needs to make - which shading language should we use? 08:52:51 https://github.com/gpuweb/ 08:53:01 Specification at https://gpuweb.io/ 08:53:26 Judy has joined #webgpu 08:53:26 https://webgpu.io/ ? 08:53:33 yeah sorry 08:53:40 present+ Judy 08:53:53 ???: About performance. You mentioned a microbenchmark. Do you have any data on real world applications? 08:54:01 q+ 08:54:09 myles: not yet, because there isn't much real world content. we're working on it. 08:54:11 q? 08:54:32 myles: we could port an existing benchmark 08:54:35 ack sangwhan 08:54:42 Zakim has joined #webgpu 08:54:52 sangwhan: you mentioned multiple languages. when do you think that will be resolved? 08:54:55 ningxin_hu has joined #webgpu 08:54:57 majidvp has joined #webgpu 08:55:22 myles: we have a meeting next week. Hopefully we can work it out. 08:55:41 sangwhan: there is a TAG process for helping to resolve issues like this. 08:56:01 ???: are you going to develop a shader compiler? 08:56:20 s/???/narufumi/ 08:56:27 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 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 myles: for example, the SPIR-V compiler is a separate project. 08:57:12 q+ to ask how shaders will be shipped around 08:58:55 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 q? 08:59:26 myles: we are hoping that the overhead of Web -> platform is only 10% more than native -> platform 09:00:15 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 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 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 ... transcode to than others? 09:01:58 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 myles: we will choose the web when there is a conflict on API design 09:02:26 ack sangwhan 09:02:26 sangwhan, you wanted to ask how shaders will be shipped around 09:02:37 sangwhan: how are shaders delivered nowadays? 09:02:47 ack Iwamoto 09:02:50 myles: SPIR-V is a byte code. WSL is a text language. 09:02:57 sangwhan: does it run on the main thread? 09:03:38 rrsagent, draft minutes 09:03:38 I have made the request to generate https://www.w3.org/2019/09/18-webgpu-minutes.html Judy 09:03:57 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 has joined #webgpu 09:04:21 ningxin_hu: we also have to consider threadgroup read. did you cover that area? 09:05:02 ningxin_hu: some kind of API in WebGPU for threaded reads? 09:05:11 idcc has joined #webgpu 09:05:39 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 ningxin_hu: sometimes the hardware vendors are much faster to innovate on features. how will the WebGPU API keep up? 09:07:23 myles: we'll always be on top of the core APIs. We can only expose what they expose. 09:07:23 present+ 09:07:42 Chair: Myles Maxfield 09:08:35 myles: we only add an extension if it exists on multiple bits of hardware 09:08:46 Meeting: TPAC 2019 breakout session on WebGPU 09:08:52 Michael Li: What does non-graphics computation look like? 09:08:59 e.g. machine learning 09:09:26 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 myles: and it is pretty easy for us to map the programming model for the platform APIs onto WebGPU. 09:10:46 ???: There are some devices that are compute-only. Could they be supported by WebGPU? 09:10:58 dino 09:11:23 dino: are you talking about ML hardware? 09:11:23 ???: yes 09:11:23 myles: we haven't discussed it 09:11:30 myles: please open an issue on WebGPU about that. 09:12:49 dino: It might be difficult to find a base set of features that we could expose everywhere 09:14:01 ...if possible get a device that only does generic computer cause that's what you need 09:14:16 ...and you can expose new operations... 09:14:20 ???: feature detection might work. similar to the way you select low power and high power. 09:14:25 ---- end ---- 09:14:31 RRSAgent, make minutes 09:14:31 I have made the request to generate https://www.w3.org/2019/09/18-webgpu-minutes.html dino 09:50:15 dbaron has left #webgpu 11:55:32 tidoust has joined #webgpu 13:19:09 Zakim has left #webgpu 13:51:46 Judy has joined #webgpu 16:17:46 Judy has joined #webgpu