Minutes for the 2017-05-31 meeting

GPU Web 2017-05-31



Chair: Corentin

Scribe: Dean (with help)

Location: Google Hangout
Minutes from last meeting
<http://www.w3.org/mid/CAGdfWNPW4uVGdBM6EPKAVTWY47dZdbz9EueLGNeAE=3HYVBtag@mail.gmail.com>Tentative
agenda

   -

   Administrative stuff (if any)
   -

   Using the WebGPU Name


   -

   Topics we didn’t get to last meeting


   -

   Binding model (i.e. how textures, uniforms are passed to shaders)
   -

   Base explicit API concepts (pipelines, command buffers, queues)
   -

   Render-targets / render passes
   -

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

   How to reach consensus on WebVulkan vs the alternative


   -

   Agenda for next meeting

Attendance

   -

   Chris Marrin (Apple)
   -

   Dean Jackson (Apple)
   -

   Jason Aftosmis (Apple)
   -

   Julien Chaintron (Apple)
   -

   Myles C. Maxfield (Apple)
   -

   Warren Moore (Apple)
   -

   Theresa O'Connor (Apple)
   -

   Austin Eng (Google)
   -

   David Neto (Google)
   -

   Ken Russell (Google)
   -

   Kai Ninomiya (Google)
   -

   Zhenyao Mo (Google)
   -

   Ricardo Cabello (Google)
   -

   Corentin Wallez (Google)
   -

   Aleksandar Stojilijkovic (Intel)
   -

   Daniel Johnston (Intel)
   -

   Rafael Cintron (Microsoft)
   -

   Ben Constable (Microsoft)
   -

   Chas Boyd (Microsoft)
   -

   Jeff Gilbert (Mozilla)
   -

   Dzmitry Malyshau (Mozilla)
   -

   Kirill Dmitrenko (Yandex)
   -

   Doug Twilleager (ZSpace)
   -

   Elviss Strazdiņš
   -

   Joshua Groves

Admin items

   -

   Nothing

Using the WebGPU Name

   -

   CW: We’ve been using different names. I asked Dean if we’re ok with
   using “WebGPU”. He’s ok with that.
   -

   RC: I think it’s fine, but it is already in use in a few places. We
   might have to come up with something different eventually.
   -

   CW: Name of Github org is gpuweb because webgpu was already taken.
   -

   MrDoob: It doesn’t matter if the project already is taken on github,
   because users can have projects with the same name.
   -

   Kirill: Is it is really a concern that we can’t use the “WebGPU”
   organisation on Github? Does
   -

   Dean: problem would be if WebGPU is trademark, asked marketing at Apple
   to figure out. Would certainly be open to giving it to the CG/WG.
   -

   CW: There is already a software library with the name WebGPU. That might
   be confusing.
   -

   Dmitri: Using WebGPU might be confusing because it’s Apple’s proposal.
   Can we start calling that WebMetal?
   -

   DJ: Yes, sure.



RESOLVED: Use “WebGPU” for now. Refer to Apple’s proposal as WebMetal.
Binding model (i.e. how textures, uniforms are passed to shaders)

   -

   CW: We looked in to this. The Vulkan model is the most constrained, so
   maybe is the one we start with as a lowest common denominator.
   -

   Dmitri: There is another constraint in D3D12, which is that you can’t
   mix samplers and non-samplers in the same descriptor heap
   -

      ACTION: cwallez/kainino: add this to the Binding Models Investigation
      doc
      -

      RESOLVED: it is linked below.
      -

   CW: I’m not sure it is a limitation. Is there a performance concern?
   -

   RC: I don’t know the answer. I’ll check. I think we should go for a LCD
   approach in general.
   -

   CW: Metal has a bunch of arrays for textures and samplers and uniforms.
   You set them all inside that. D3D you have a set of descriptors, and you
   pass ranges into those sets. Vulkan is slightly similar to D3D12. That’s
   why our conclusion is that Vulkan is the most performant and flexible
   towards other APIs.
   -

   RC: OK. Let’s go with that for now. I’ll get back to the group if we
   think there are issues.



(Digression into Compute Shaders)



   -

   KR: I think we skipped over this too fast. Could someone give a
   presentation on this, so we’re not give giving a cursory overview?
   -

   JG: I think a concrete proposal might be more useful. Establish the
   proposal and talk about it. A tutorial here might not be the best use of
   time.
   -

   KR: We don’t have a common proposal.
   -

   KR: It’s not clear to me how designing or deciding on a binding model in
   isolation will mesh with some vendor’s goal to simply follow a particular
   API. e.g. Mozilla with Vulkan
   -

   JG: I’m not sure we’ll be choosing between proposals. Rather, we’ll
   iterate on a single suggestion.
   -

   Kirill: There is 3D portability work going on at Khronos trying to do
   the same thing: find an API that works on all platforms.
   -

   CW: The focus there will likely be on making a subset of Vulkan. By
   default the design will be like Vulkan. I don’t think we can take much from
   that work.
   -

   MM: My claim is that since we’ll be rewriting shaders and new APIs, we
   can assume that any of the APIs is implementable on each other. Is this
   true?
   -

   CW: Yes, but not always in a performant manner. For example, Vulkan
   needs to describe the layout of the bindings, where Metal doesn’t. So to go
   from Metal’s model, you’ll need to rewrite things at runtime.
   -

   JG: I think we need to move from this proposal in concept to something
   in words we can discuss. You need to understand all three APIs.
   -

   CW: Take it to a github issue?
   -

   RC: I agree with Jeff. Describe what the API would mean in all three
   platform APIs. Maybe even a prototype. Definitely needs to be more than
   simply a 1 hour conversation.
   -

   CM: Or a strawman with some description of how it maps to the platform
   APIs.
   -

   JG: Agreed. Strawman + iteration.
   -

   KR: There is a document and strawman linked here
   <https://docs.google.com/document/d/1_xeTnk6DlN7YmePQQAlnHndA043rgwBzUYtatk5y7kQ/edit#heading=h.240dgd2ksmw6>
   -

   CW: This was made as part of Google’s NXT prototype (only Metal and
   OpenGL backends). Vulkan backend will be easy. D3D12 won’t be too bad.
   -

   Ben: Why would D3D12 be more difficult than Vulkan?
   -

   CW: Because we used the Vulkan model as the API. D3D12 would have to
   emulate Vulkan descriptor layout and pools with root signatures and
   descriptor heaps respectively
   -

   Ben: why not use the D3D12 model? How did you pick Vulkan?
   -

   CW: D3D12 descriptor heaps are too flexible w.r.t Vulkans descriptor
   sets.
   -

      Slides for Vulkan
      <https://docs.google.com/presentation/d/12YSEcLjyYStNDK9EwhPgRq05oIxpTIqC1GdKgJd_Jt4/edit#slide=id.g17c6be9a5e_1_122>
      -

      Slide for D3D12
      <https://docs.google.com/presentation/d/12YSEcLjyYStNDK9EwhPgRq05oIxpTIqC1GdKgJd_Jt4/edit#slide=id.g17c6be9a5e_1_218>
      -

   CW: (Shows the slides on Vulkan and D3D12 binding model)
   -

   MM: If we are going with a model with the descriptor set up front, it
   doesn’t seem like the proof of concept is complete, so we need to have at
   least one new backend.
   -

   CW: Our intern Austin will work on a D3D12 backend. Our analysis was
   that it will be pretty fast translation.
   -

   JG: We don’t require P.o.C that things are possible. A lot of it will be
   API investigation.
   -

   MM: Since Apple’s implementation will be on Metal, it shouldn’t matter
   too much to us.
   -

   CM: I would like to see some P.o.Cs
   -

   JG: We’re writing code and deep into specifications.
   -

   Ben: I think these runtimes are complicated and it is informative to
   write the code. Especially with things like Vulkan and D3D12, the
   specification is not enough to understand all the interactions. I think an
   implementation like NXT will allow us to find the hidden issues.
   -

   JG: Agreed in general. The Vulkan spec is pretty good. D3D12 and Metal
   are less detailed specifications.
   -

   Ben: In our case it was more about trying it on all hardware, rather
   than the specification itself. E.g. the debug layer that removes
   performance, but gives you lots of feedback about what you did wrong. Doing
   that with NXT would be helpful.
   -

   JG: Vulkan has a validation layer, but those are all detailed in the
   specification.
   -

   CW: I think the point is that we don’t have detailed specifications on
   Metal and D3D12, we just have programming guides. Vulkan does have a
   specification.
   -

   Ben: I can take an action to see if we can open up a specification on
   D3D12, the way we do with IHVs.
   -

   Ben: I’ll also help with any work in a D3D12 backend to NXT.
   -

   CM: We had a similar issue with WebGL. Different implementations had
   different constraints. That’s why we were reliant on implementations. I’m
   not sure better documentation would help completely.
   -

   JG: The documentation helps the design process.
   -

   CW: Suggestion that the Vulkan specification helps because it is more
   detailed. Anything we have in that area is useful.
   -

   CW: Do we need a prototype to decide on API directions?
   -

   JG: I don’t think we do.
   -

   KR: I strongly suggest we require prototypes that give us understanding
   on all the backends.
   -

   Ben: I completely agree with what Ken said. We need to go wide before
   deep.
   -

   CM: I third that. We are breaking new ground. We have to try things out.
   -

   JG: The problem is that we trust the prototype without understanding the
   implementation requirements. We only built the prototype to superficial
   requirements.
   -

   Ben: It’s just a prototype to inform discussion. I will never trust what
   we are building if we don’t have a prototype. Are you worried that people
   will get attached to the code?
   -

   JG: It’s more about misunderstanding the API. e.g. write a test, a
   prototype, everything looks good but you have a misunderstanding about the
   general case. Your specific cases work.
   -

   CW: We should evaluate the prototype design, and investigate all the
   specifications.
   -

   Ben: If we get it wrong, we iterate. The prototype is informative.
   -

   JG: Worried that we will short-cut understanding.
   -

   Ben: (describes that a prototype from MS would have deep understanding
   of D3D12 - which is better than a specification)
   -

   Chas: We’ve learnt through D3D12 that reference source code is better
   than specifications. Use Github to have multiple implementers contribute
   code.
   -

   CM: WebGL benefitted from having multiple implementations, to inform the
   specification.
   -

   CW: That’s the idea of an MVP.
   -

   CW: We’re working hard on NXT. Coming up with a D3D12 backend soon.

Compute Shaders

   -

   Elviss: What about calculation APIs like OpenCL? Could this be used?


   -

   CW: There is a goal for compute shaders. It’s not quite the same.
   -

   Elviss: Is it textures?
   -

   JG: Do we want compute in V0?
   -

   CW: I think so.
   -

   JG: I’m not sure. It’s useful, but should be on the cutting block if
   necessary.
   -

   CW: Lots of engines use compute shaders.
   -

   MM: Compute shaders are conceptually more simple than graphics pipeline,
   so I don’t think we should rule it out now.
   -

   RC: It depends on how long it takes (beyond drawing a triangle). Let’s
   get feedback on graphics first and build compute as we’re iterating.
   -

   CW: The biggest difficulty will be getting the shader translator
   working, due to the fact they have random access to memory inside the
   shader. It will be difficult to secure.
   -

   Dmitri: Tempting to only support one graphics queue if you don’t do
   compute.



RESOLVED: Compute Shaders to be in the MVP, but not a top priority.
Agenda for next meeting

   -

   Topics for next meeting. Proposal:
   -

      Base explicit API concepts (pipelines, command buffers, queues)
      -

      Render-targets / render passes
      -

      Stuff that doesn’t go in (XFB?)



   -

   RC: Eventually we’ll have to have the day of reckoning about shaders :)