Re: Minutes for the 2017-05-24 meeting

That was Elviss.


On Wed, May 24, 2017 at 3:30 PM, Kirill Dmitrenko <dmikis@yandex-team.ru>
wrote:

> It wasn't me who told about using samplers for restricting memory access.
> Unfortunately I didn't catch who did.
>
> Kirill Dmitrenko
> Yandex Maps Team
>
> 25.05.2017, 01:22, "Corentin Wallez" <cwallez@google.com>:
>
> 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
>
>