<scribe> scribenick: dino

Myles: Hi I'm Myles Maxfield. Work for Apple on the WebKit team.
... our clear goals are -

1. high level background

2. get feedback

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.

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.

OpenGL has a long history, and the current API doesn't map very well to modern hardware.

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.

And it also exposes compute functionality to the Web.

3 APIS are Metal (Apple), D3D12 (Microsoft) and Vulkan (Khronos)

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.

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.

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.

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.

myles: (shows a demo of a babylon.js model that works in Safari + Chrome with WebGPU turned on)

question: what GPU is this demo using?

myles: this is the integrated Intel GPU

question: what about performance compared to WebGL?

myles: we wrote a basic benchmark to measure this. Our results show that WebGPU is between 2x and 8x "faster" than WebGL.
... what's interesting in our benchmarks is that we are now mostly bound by the GPU, not the CPU.
... so why are we getting better performance compared to WebGL?

- shows coloured cube. explains vertex data.

myles: the way you would do this in WebGL is to describe the state on each draw call.
... 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++
... similarly for binding - in WebGL you have to bind all the textures each draw. In WebGPU you can save the collection of bindings.

mike: what do you mean my validation?

myles: when you create these batch objects, we are calling directly into the hardware and referencing an opaque thing.
... talk about the future of the group.

(shows an image of a checkered flag)

notice that it isn't just black and white, there are ripples, and reflections, and bloom and highlights

this is done by a program that runs to work out the output of each pixel

these are called shaders

<dbaron> SPIR-V versus Web High-Level Shading Language (WHLSL) ??

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.

This is the next big decision that the group needs to make - which shading language should we use?

https://github.com/gpuweb/

Specification at https://gpuweb.io/

<jbroman> https://webgpu.io/?

yeah sorry

???: About performance. You mentioned a microbenchmark. Do you have any data on real world applications?

myles: not yet, because there isn't much real world content. we're working on it.
... we could port an existing benchmark

sangwhan: you mentioned multiple languages. when do you think that will be resolved?

myles: we have a meeting next week. Hopefully we can work it out.

sangwhan: there is a TAG process for helping to resolve issues like this.

narufumi: are you going to develop a shader compiler?

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.
... for example, the SPIR-V compiler is a separate project.
... 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.
... we are hoping that the overhead of Web -> platform is only 10% more than native -> platform

kip: WASM story. Do you have a story about how to port native apps e.g. a MoltenVK type of system that wraps WebGPU

myles: there isn't a final answer yet on how to expose WebGPU to WASM. We are interested but just not ready.

<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

myles: when we talked to developers who have experience with WebGL they said they are fine with a JS API for now.
... we will choose the web when there is a conflict on API design

<Zakim> sangwhan, you wanted to ask how shaders will be shipped around

sangwhan: how are shaders delivered nowadays?

myles: SPIR-V is a byte code. WSL is a text language.

sangwhan: does it run on the main thread?

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.

ningxin_hu: we also have to consider threadgroup read. did you cover that area?
... some kind of API in WebGPU for threaded reads?

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.

ningxin_hu: sometimes the hardware vendors are much faster to innovate on features. how will the WebGPU API keep up?

myles: we'll always be on top of the core APIs. We can only expose what they expose.
... we only add an extension if it exists on multiple bits of hardware

Michael Li: What does non-graphics computation look like?

e.g. machine learning

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.
... and it is pretty easy for us to map the programming model for the platform APIs onto WebGPU.

???: There are some devices that are compute-only. Could they be supported by WebGPU?

dino

dino: are you talking about ML hardware?

???: yes

myles: we haven't discussed it
... please open an issue on WebGPU about that.

<Judy> dino: It might be difficult to find a base set of features that we could expose everywhere

<Judy> ...if possible get a device that only does generic computer cause that's what you need

<Judy> ...and you can expose new operations...

???: feature detection might work. similar to the way you select low power and high power.

---- end ----

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/???/narufumi/
Present: jeff Judy dino
Found ScribeNick: dino
Inferring Scribes: dino

WARNING: No "Topic:" lines found.


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)