<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?
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.)[End of scribe.perl diagnostic output]