Minutes for the 2017-05-24 meeting

Hey all, here are the minutes for the meeting.

GPU Web 2017-05-24



Chair: Corentin

Scribe: Dean with lots of help

Location: Google Hangout
Attendance:

   -

   Chris Marrin (Apple)
   -

   Dean Jackson (Apple)
   -

   Myles C. Maxfield (Apple)
   -

   Jason Aftosmis (Apple)
   -

   Julien Chaintron (Apple)
   -

   Theresa O'Connor (Apple)
   -

   David Neto (Google)
   -

   Ken Russell (Google)
   -

   Kai Ninomiya (Google)
   -

   Zhenyao Mo (Google)
   -

   Ricardo Cabello (Google)
   -

   Shannon Woods (Google)
   -

   Corentin Wallez (Google)
   -

   Aleksandar Stojilijkovic (Intel)
   -

   Rafael Cintron (Microsoft)
   -

   Ben Constable (Microsoft)
   -

   Chas Boyd (Microsoft)
   -

   Jeff Gilbert (Mozilla)
   -

   Dzmitry Malyshau (Mozilla)
   -

   Daosheng Mu (Mozilla)
   -

   Fernando Serrano (Mozilla)
   -

   Kirill Dmitrenko (Yandex)
   -

   Doug Twilleager (ZSpace)
   -

   Elviss Strazdiņš
   -

   Joshua Groves


Meeting planning

   -

   Ken: Can we please send out meeting reminders the day before?


   -

   Dean+Corentin: Yes


Mailing Lists

   -

   All members should be on internal-gpu automatically
   -

   You might have to manually join public-gpu (@dino will check)


Administration

   -

   Corentin: Dean, do you know if there is anything specific to do?


   -

   Dean: not that I know
   -

   Dean: About the charter, there is one thing left to do, Apple and Google
   working on a clause to make software deliverable are usable by anyone
   without IP licensing issues.
   -

   Corentin: We haven’t spoken to the lawyers in a while. I’ll check up
   with them.
   -

   Kirill: will the discussions between lawyers be with the W3C lawyers?
   -

   Dean: Yes they are involved, and the result will be run through the PSIG
   group (Patent <something> Interest Group) at the W3C. The work will not be
   done in isolation.


WebAssembly-style MVP

   -

   Dean: WebAssembly followed an MVP <http://webassembly.org/docs/mvp/>
   approach, could be good to follow the same path to get thing out fast.
   -

   Jeff: I think it is a useful approach. Hopefully we won’t punt on
   something that will turn out to be necessary later.
   -

   Corentin: WASM has a versioning system, where version=0 is the MVP, but
   as soon as it is released it becomes version=1 which will require
   recompilation
   -

   Ben (MS): I like the idea of an MVP. Allows us to go broadly on
   architectural design, without going too deep. We can innovate.
   -

   Jeff: I don’t want backwards compatibility to be a non-goal. We should
   try to keep compatibility as much as possible. While we are developing, we
   can make changes…
   -

   Chris Marrin: Looking back at WebGL, non bw-compat as long as we are
   willing to support all versions forever
   -

   Jeff: for WASM it is easy to update to the newer spec, you mostly have
   to recompile with an updated emscriptem and it works. For GPUWeb it would
   require code changes.
   -

   Ken: The mechanism that worked pretty well in WebGL was using the
   browsers’ development channels and feature flags. We don’t ship things that
   are not conformant to the specification. Making changes after shipping is
   difficult. Encourage people to not ship until they are conformant.
   -

   Kai: regarding WASM, the cross compiler will have a shim that runs WASM.
   If the browser doesn’t support the version, it falls back to JS. So it runs
   slowly rather than not at all.
   -

   Jeff: There are things in WebGL we’d like to get rid of, but we haven’t
   done it so far. The idea would be that we could keep support but not worry
   about optimizations.
   -

   Chris: It’s not good commercial practice to make some things slow
   intentionally.
   -

   Corentin: We’re talking about during the development of the GPU
   specification, not after specification.
   -

   Jeff: I think WebGL will be more broadly used because it is a core part
   of the Web that you can rely on. It will take a while for work here to get
   to that point. It’s also about providing the lower-level features - not
   replacing WebGL.
   -

   Chris: WebGPU will be used for more than graphics (compute).
   -

   Jeff: (disagrees)
   -

   Dean: (agrees with both ^^) consensus is to maintain bw-compat if
   practical during development, but break stuff if needed, but after version
   1, bw-compat should be maintained as much as possible
   -

   All: consensus
   -

   @Dean - send/github a description of the MVP-like approach for discussion


Technical Features

   -

   Corentin: Last week we talked about high-level goals but Jeff pointed
   out it would be great to talk about features too, in here is a tentative
   list of features to talk about.

JS Binding to GPU API

   -

   Jeff: I’ve been poking around with our prototype. I’ve been using
   handles. WASM doesn’t have concepts of objects, so at least the binding for
   WASM will need handles. For this we need to be aware of race-conditions
   (where one thread creates an object and another thread deletes it).
   -

      Create an object, get a handle, it has a ref count.
      -

      Use that object via the API with the handle
      -

      Delete the object, decrement the refcount but it is still “alive”
      -

      I don’t think we can tolerate the Vulkan-like model of requiring the
      developer to keep track of object lifetimes
      -

   Rafael: WASM doesn’t have threading yet. But for Workers, I think we
   should do explicit hand-off for the moment. E.g. Main thread gives the
   worker the command buffer, and then the main thread can’t write to it.
   -

   Corentin: I generally agree. Although with these explicit APIs, the
   objects are immutable, so once it is built you should be able to transfer
   ownership to a worker.
   -

   Dean: I am in agreement for WASM. I’d like a JS friendly API, which
   could be an extra deliverable.
   -

   Corentin: Agrees that objects are nicer for JS, but for browser dev’s
   sanity we should keep WASM and JS API very similar. The nice to use JS
   library could be a library that’s a software deliverable that is
   implemented over the “low-level” JS API.
   -

   Jeff: The problem with thread-handoff is that native apis don’t need it,
   so it would mean cross compilation needs some extra work
   -

   Kirill: The rationale that we may not need to make WebGPU resources in
   JS with exclusive ownership, is ok, because the native tools have more
   explicit sync features where as JS only has atomics at the moment. Just
   being able to do work by handing it off to another thread will be a big win
   - we spend a lot of time creating resources on the main thread.
   -

   Jeff: If “some game” had a Metal backend, and wanted to port to the Web,
   they wouldn’t have any explicit markers in their code for when to do
   handoff, because native APIs don’t need it.
   -

   Myles: There will be a requirement to do this work anyway, because it is
   required for the Web. There needs to be a way for the browser to know which
   thread owns an object.
   -

   Jeff: I think we can do synchronisation …
   -

   Rafael: I was talking about command buffer generation.
   -

   Jeff: Yes, my idea was that a command buffer is locked for write to the
   thread. Once you are done writing, another thread could take ownership.
   Someone will write something that mutates CBs from multiple threads, but I
   think that’s a weird edge case that we don’t need to support.
   -

   Jeff: We could also have two types - one is synchronised on every write,
   the other has a locking mode. It would be interesting to see performance.
   -

   Kirill: You’re suggesting treating every object as an atomic. Each
   thread has exclusive access.
   -

   Jeff: Not exclusive. Mutually exclusive.
   -

   Ben: One thread at a time, but it can move between threads.
   -

   Chris: This seems like a reasonable restriction for MVP.
   -

   Jeff: Agreed.
   -

   Corentin: Let’s take the discussion to github/mail.
   -

   Jeff: I’ll talk to Mozilla’s WASM. While we won’t have pthreads, we will
   have SharedArrayBuffers. This means we should design our API with the idea
   that we effectively have pthreads (a Web-version)
   -

   Chris: So it’s not part of WASM at the moment, but available separately
   via SharedArrayBuffers?
   -

   Jeff: yes


Where to talk about technical issues?

   -

   Jeff: Github issues are better, not convenient to browse mailing-list
   archives
   -

   Dean: will post to github (minutes)


Shading Language

   -

   Corentin: Are we decided on a binary or source language?
   -

   Kirill: both
   -

   Ken: feedback from WebGL that a binary format was strongly desired.
   Encourage avoiding duplication - this will be a nightmare if there are
   multiple formats. WASM could provide a compiler at run time. Let’s try only
   having a binary format at first.
   -

   Elviss: working on my own language and would be better to have binary
   format
   -

   Jeff: we should have a non-text IR. Using “binary-format” is confusing.
   Might imply a GPU-specific, non-introspectable binary.
   -

   Corentin:I think we are all talking about non-text IR.
   -

   Chas: We’ve seen (microsoft) that our non-text IR formats don’t save a
   huge amount of time because the drivers recompile and optimize it anyway.
   -

   Corentin: We’ve seen something similar in ANGLE.
   -

   Chas: Occasionally we see a pathological case in the D3D compiler, but
   our new compiler (based on clang/llvm) is usually able to avoid these cases
   and be much faster.
   -

   Jeff: I hope that new compiler is available as a DLL, so that we could
   ship it with Firefox.
   -

   Chas: It’s on github, so you can get it. There is a system component
   that does some validation, but it might not be necessary.
   -

   Dean: we did preliminary investigation of binary format, concern that it
   is hard to validate. Someone? mentioned it could be worth investigating a
   WASM-like format with a type for buffers. What confidence do people with
   experience with SPIRV? Can it be easily validated?
   -

   Chris: I wonder the same thing.
   -

   Ken: WASM doesn’t prove there aren’t OOB, it just guarantees that it
   doesn’t break the rest of the page(?). OpenCL did a fat-pointer
   implementation, and claim that it added about a 10% performance penalty.
   -

   Ken: we could predicate WebGPU on the presence of well-tested robustness
   behavior that give some sort of guarantee for OOB buffer and texture
   accesses
   -

   Chas: if you declare something as a graphics buffer type, it can use
   fixed-function HW to do accesses, and ensure that OOB is robust. Not the
   same for compute.
   -

   Chas: IHVs are unhappy to do the validation. But for the Web we need
   that guarantee.
   -

   David: In SPIR-V the buffer size is not represented explicitly in the
   SPIR-V module; the implementation would have that associated along with the
   buffer binding. Then it’s the backend’s responsibility to do the bounds
   check.
   -

   Chas: that’s how it works in DXIL, using indices typed on the stride of
   the buffer. We ask the HW to be able to have virtual memory and use pages
   to provide security (might be a bit incorrect didn’t catch all of this)
   -

   Jeff: you won’t see data from a different process?
   -

   Chas: correct
   -

   Corentin: We need a per-context address space that can’t see data from
   another context.
   -

   Jeff: (describes the process per tab/GPU process model in browsers)
   -

   Kirill: There is a sampler object in SPIR-V that describes what happens
   when you access out of bounds (e.g. clamp, wrap, something else)
   -

   Corentin: This works for fixed-function work, but there isn’t hardware
   support for this with buffer access.
   -

   Chas: We might be able to require the IHVs to use their sampler hardware
   for these operations. But there is the possibility of a performance hit.


Topics we didn’t get to this meeting

   -

   Explicit API concepts
   -

   Binding model (i.e. textures, uniforms)
   -

   Render-targets / render passes
   -

   Stuff that doesn’t go in (XFB?)
   -

   How to reach consensus on WebVulkan vs the alternative