– DRAFT –
WebGPU TPAC breakout session

WebGPU overview

Corentin: I chair the GPU for the Web Community Group, developing WebGPU.
… First question that usually gets raised is: why not WebGL instead?
… WebGL has a lot of historical bagage, which creates lot of CPU overhead. And also it does not map very well to modern graphic cards.
… The driver may be doing stuff for 100ms in some cases, resulting in dropped frames.
… WebGL does not expose computation capabilities either.
… And also, recently, Apple deprecated OpenGL.
… WebGPU is like WebGL but more modern and without issue.
… It's inspired by modern GPU APIs (Metal, D3D12, Vulkan). It isn't any of them in particular, but close to them in particular.
… Enables things such as faster games, more efficient machine learning on the Web, etc.
… Who's doing WebGPU? It's a W3C CG, and maybe soon as WG. Main browser vendors are engaged. Significant contributions from Intel and Yandex as well, for instance.
… When will it be ready? We don't know, but we're making good progress on the API that allows scheduling of the computation on the GPU.
… The discussions on the shading language are more difficult and progress has been slower on that front than expected.
… Early next year, we'll have a good-enough-though-not-completely-stable API that we can share around and play with.

Jungkee: How is this API going to be consumed by the upper layer?

Corentin: WebGPU is an abstraction layer over doing graphics. We don't expect a lot of people will use WebGPU directly for actual Web sites.
… The expectation is that most of the usage will be through frameworks.

<wseltzer> ... or game engines

Corentin: Babylon.js, three.js are considering support for instance.

<wseltzer> ... unity and unreal

anssik: If you're moving to WG, how will the scope be different?

Corentin: The WG would be for stamping the spec, for IP reasons.

Arno: Do you consider an OpenCL replacement as well?

Corentin: OpenCL had some security issues, which is why WebCL did not progress, but the functionality should be there.

Zhiqiang: Do you have some typical use cases that compare use of WebGPU vs. use of WebGL?

Corentin: One reason is advanced games.
… Another reason is that you'll be able to push more scene complexity, because the CPU overhead is smaller.

Zhiqiang: Do we have some concrete benchmarks?

Corentin: We had some early prototype, but we're still working on integrating the new proposal inside browsers.

Yang: Some ongoing effort to port "Aquarium" for benchmark.

Corentin: Intel is working on WebGL2 Compute, but it's unclear when it will be done, and also won't work on Mac.

sangwhan: Is non browser GPU also a goal for this?

Corentin: Yes, definitely.

WHLSL

Myles: Want to talk about a new shading language.

<Kangz> WHLSL

Myles: Corentin explained that WebGPU needs to work across hardware platforms. All of these platforms have different shading languages.
… Requirements for WebGPU: language needs to be safe! That's a non starter if the language isn't safe.
… It obviously also needs to be well-specified.
… Then translatable across the 3 different platforms.
… It needs to be performance.
… Some features need to be evolved together between WebGPU and the shading language.
… Lastly, since it's new, it would be good if it could be easy to read and write.
… Really quick tour through the existing languages:
… Metal Shading language is C++ based. But not safe since you can cast pointer into integers back and forth.
… HLSL isn't fully defined.
… GLSL is the language that WebGL shaders uses. GLSL tends out to be a very difficult language to use because of its historical baggage.
… SPIR-V is an interesting choice but it isn't one that humans write.
… JS is also intersesting, but not typed-enough, e.g. a+b. It would be very slow.
… WebAssembly is yet another interesting idea. But not fully adpated for GPUs, including memory layout.
… Taking all that into account, we came up with a new one, WHLSL.
… The spec contains rules, which is more than a grammar. It defines things such as how types work, and the execution environment.
… There is also a compiler, which produces SPIR-V, MSL, HLSL
… This is not in any browser yet.

[showing an example]

Myles: The example shows the source, the result of the compilation, here for a Mac, and the rendering.
… I could talk about the details of the language.

anssik: How did you come up with this proposal? Massaging the different proposals?

Myles: Most of the work was done by the Webkit team. We're in the process of inviting other perspectives.

Corentin: In the group, there are people who believe that the browser should support SPIR-V and others that browsers should support WHLSL directly. Complicated discussions.

Bryan: How to WHLSL compare to HLSL in a more secure version?

Myles: That's basically what this is.

sangwhan: is this proposal available for review anywhere? how is the demo implemented?

Myles: The compiler in the demo outputs intermediary language that gets ingested by my machine directly, not running in the browser for now.

Corentin: The advantage that we have compared to compute functionality is that you can do matrix multiplication more easily. I can go way deeper on this, it's complicated.

Arno: What kind of use cases are you thinking about?
… Are you thinking about machine learning for instance?

Corentin: Yes.
… It would help with machine learning, fluid computations, effects in rendering applications.

Arno: Where does the compilation happen?

Corentin: The results of the discussion on the computation language does not really change anything.
… The compilation happens when you load the application.

Myles: Same as in WebGL.

Corentin: Capabilities don't matter for this, because both languages have the same ones.

Arno: If the compilation happens in the browser or if the compilation happens before, it's different. The application could generate shaders on-the-fly in the second case for instance.

Myles: The Web author could go back to the server, or serve the source and a compiler at the same time.

Ben: For WebAssembly, sometimes, the compilation time sometimes makes a difference.

Corentin: The compilation time is not so much of a problem. Register allocation is the most complicated issue in our context for various reasons, takes an insane amount of time.
… Compilation time is not a differenciation criterion.
… Every vendor comes with its own set of requirements. Goal is to have it run on all Windows 10 devices, a large number of Windows 7 devices, Android devices.

Myles: Metal and D3D have a small number of configurations that you can change. Vulkan has a zillion of such configurations.

sangwhan: Is the current proposal different from the language that was "shipped" in Safari?

Myles: Yes, different. That was a proof of concept to prove performance gains. Now we have data.

Ben: Some kind of software fallback?

Corentin: Yes, plugging things together, you'll be able to do that.

?8: Is is going to replace WebGL2 entirely?

Myles: WebGL is part of the Web Platform. We do want to say that WebGPU can be used in all areas where WebGL can be used.

Guido: [scribe missed question]

Corentin: Overhead target should be minimal. GPU performance is super important for us.

Ben: You mentioned WebAssembly API as a maybe. Anything WASM can do to help with that?

Corentin: We had exchanges on that with the CG. Host bindings is one. That should give us most of what you need.

Ben: Integers and floats are easier to pass in WASM. WebGL passes strings and arrays in a number of places, I believe.
… Is there a way to make the API easier for pre-host bindings?

Corentin: We're looking at dictionary-based solutions, because it's not the fast path.

?9: A possible future where WHLSL can be used in WebGL as well?

Myles: That hasn't been discussed.

[Some discussions on shading languages, compilers]

ningxinhu: Any plan to support tooling to port Metal Shading Language and others to WHLSL?

Corentin: First, HLSL is close to WHLSL. Also any shading language compiles to SPIR-V, so that's a common intermediary. But depends on the outcomes of related discussions.

ningxinhu: WHLSL is for humans, not for compilation output?

Myles: It's actually for both. That's an explicit goal that I should have listed.

?10: Possible to decompile SPIR-V into WHLSL?

Corentin: That should be roughly doable.

Myles: Any arbitrary SPIR-V program cannot, though.

Corentin: Some operators in SPIR-V are blocked.

?8: is the goal to support multiple GPUs?

Corentin: That's explicitly something we thought about, but then it's too complicated and probably too niche on the Web.

?8: Scientific research would benefit from it.

Myles: That's a great thing to explore in the future.

Corentin: Right. To be honest, I would be surprised.

sangwhan: GPU context switching?

Corentin: The idea is that there is no GPU switching. But you can choose low- or high-performance.

sangwhan: And that gives you the GPU model?

Myles: Unclear. We don't want to expose information unless needed.

Bryan: Will WebGPU WHLSL have extensions?

Myles: Unclear.

Corentin: We are thinking of an extension mechanism. For instance, you could imagine Raytracing extensions. But the plan is to remain conservative.

?10: Is multiview in case?

Corentin: We haven't thought about multiview, but that's a bandage, to be honest.
… Our current approach is to try to do a basic set of features that are really fast.

Myles: The purpose of multiviews is to increase performance. If that give much more performance, then that's a valuable use case.

[WHLSL is targeting feature levels on all existing platforms, so any card should be able to run it]

Myles: Google has started implementing this. Apple has started implementing this as well according to activity in public repo.
… Mozilla is prototyping things.

wseltzer: Wendy from W3C. Just wanted to say hello. Good progress there. When you mentioned transition to a WG to get IP stamps, that's valuable, especially in the GPU space.
… We're happy to help with that transition. Of course, that requires approval by the W3C Advisory Committee. So when you think you're ready, please get in touch with us.

Corentin: Awesome. I believe Dean Jackson is looking into it as well.