Minutes for the 2017-06-13 meeting

GPU Web 2017-06-14



Chair: Dean and Corentin

Scribe: Dean (with help)

Location: Google Hangout
Minutes from last meeting
<https://docs.google.com/document/d/11MOpMjj71QYk1yrcpcEyDLqPWhacBgPkR9K1TFkUtGg/edit#>Tentative
agenda

   -

   Administrative stuff (if any)


   -

   Individual design and prototype status


   -

   Look at the investigations that were made on base concepts:
   -

      Pipeline state
      -

      Command buffers
      -

      Queues
      -

   Render targets / render passes
   -

   Agenda for next meeting

Attendance

   -

   Chris Marrin (Apple)
   -

   Dean Jackson (Apple)
   -

   Myles C. Maxfield (Apple)
   -

   Austin Eng (Google)
   -

   Corentin Wallez (Google)
   -

   Ricardo Cabello (Google)
   -

   Aleksandar Stojilijkovic (Intel)
   -

   Ben Constable (Microsoft)
   -

   Rafael Cintron (Microsoft)
   -

   Dzmitry Malyshau (Mozilla)
   -

   Fernando Serrano (Mozilla)
   -

   Jeff Gilbert (Mozilla)
   -

   Alex Kluge (Vizit Solutions)
   -

   Elviss Strazdiņš
   -

   Joshua Groves
   -

   Tyler Larson

Administrative items

   -

   CW: Apparently we are not on the TPAC schedule.
   -

   DJ: I will email to make sure we get on schedule -
   https://www.w3.org/2017/11/TPAC/
   -

   DJ: I’ll try to overlap with WebVR and/or WebAssembly (tentatively
   Monday and Tuesday)
   -

   DM: WebAssmebly at TPAC
   https://github.com/WebAssembly/meetings/blob/master/2017/TPAC.md
   -

   DJ: Should we try to meet before November? Depends on attendance and
   hosting?
   -

   CW: Maybe adjacent to SIGGRAPH?
   -

   RC: I’m not around during SIGGRAPH. I agree a face-to-face meeting would
   be a good idea.
   -

   JG: Yes, meet before November but not sure when yet.
   -

   CW: Let’s talk about it on the calendar.



ACTION ITEM: Corentin to send email about a face-to-face meeting to the
mailing list.
Individual design and prototype status

   -

   CW: For NXT, Austin has done some great D3D12 work. We have triangles on
   the screen, using vertices instead of hardcoded data.
   -

   DM: on Obsidian, started to look at a binding model that combines heaps
   and pools
   -

   RC: Do you mean just one, or both?
   -

   DM: You can use both, and the backend decides which to use. E.g. Vulkan
   backend has the heap doing nothing.
   -

   RC: No update from Microsoft. Responded to the queue issue on github.
   Our lawyers are talking to Apple and Google about software license.
   -

   CW: I saw one of the drafts of this. It looks a bit like the patent part
   of Apache 2.
   -

   DJ: Nothing new to report on Apple - we’re swamped with incoming work
   from our public seeds (not WebGPU stuff)

Command buffers

   -

   DJ: still trying to get feedback from Metal team about cost of switch
   encoders
   -

   DJ: someone from the Metal team should start joining next week
   -

   DJ: Took a look at the Metal 2 binding model, looks like D3D12 and
   Vulkan binding model
   -

      Close relationship between MSL and the API, kept API simple and
      shading language expressive. That’s a general design principle.
      -

   DM: Will be good to discuss them separately, will be hard to do both
   binding model and shading language
   -

   JG: It’s true that these concepts are intertwined, but I think it is
   possible to discuss things with rough equivalence. We do often need
   background info on ‘nearby’ concepts in order to fully compare and contrast.
   -

   DM: Bothered by the fact that IAB’s are populated per entry-point.
   (shader function). Do you have to repopulate them per MTLFunction
   -

   CW: I think the idea in Metal is that you have a program with many
   functions, and the binding is associated with the program.
   -

   DM: actually I think this is MTLFunction not MTLLibrary



   -

   DM: Jump back to discussion on which commands can be executed where. Is
   it important to do Blit and Compute at the same time.
   -

   JG: Mix and match?
   -

   DM: Doing blit, then compute, then blit, etc. Rather than setting them
   up each time.
   -

   JG: I think this is possible on each API.
   -

   DM: If it isn’t important to switch between Blit and Compute, then we
   can get the encoder concept.
   -

   https://github.com/gpuweb/gpuweb/issues/21
   -

   CW: (describes the issue above)
   -

   JG: What does D3D not have?
   -

   CW: D3D requires a direct queue if you want graphics.
   -

   RC: In D3D the graphics queue can do Blit Compute and Graphics, Blit can
   only do Blit, and Compute only Compute (and Blit didn’t catch that).
   -

   RC: Vulkan has queue families with bits
   -

   CW: In Vulkan there is a guarantee that there is at least one “direct”
   (D3D speak)
   -

   MM: Do the D3D queues map to specific hardware capabilities?
   -

   CW: Yes. I expect you might have some hardware that can do both graphics
   and blits.
   -

   RC: The purpose of multiple queues is that you can do multiple things at
   the same time. E.g. graphics could happen while a blit queue is executing.
   -

   DJ: The question of Metal doesn’t the concept of a direct queue is “is
   it cheap to swap encoders”? Will investigate but assume the answer is yes.
   -

   JG: Yeah, it seems that behind the scenes the Metal command buffer will
   work out what parts of the encoded commands can be sent to various pieces
   of hardware.
   -

   JG: So all APIs are coming from the same place, with slightly different
   approaches in API exposure.
   -

   CW: Should we go forward, with the idea that Dean will double check with
   Metal, with a single command buffer that can handle all types.
   -

   RC: Stick with only one type for the MVP, unless Metal encoder switching
   is expensive
   -

   CW: In Metal, the states you set inside a RenderCE don’t get inherited
   into other CommandEncoders. Vulkan allows inheritance. So I think we should
   require all state to be set inside the Command Encoder (for Metal
   compatibility)
   -

   DM: If we don’t do inheritance from outside renderpasses to inside, then
   it is equivalent to having a render encoder. Suggest we do inheritance from
   outside the renderpass to inside.
   -

   CW: Switching render targets is an expensive operation, so this other
   information will be fairly cheap.
   -

   DJ: Sounds ok.
   -

   RC: You’re saying you define everything up front?
   -

   CW: D3D doesn’t have this problem. When you bind a RenderTarget, all the
   state is dirty and you have to completely reset. Alternatively, you have
   some persistent state in between rendering commands, outside even a render
   target block.
   -

   MM: In D3D, when you reset your commands, you have to specify a pipeline
   state?
   -

   CW: You can but not required, it is an optimization.
   -

   DM: We are effectively agreeing on the Vulkan model?
   -

   CW: That sounds fine
   -

   DJ: Happy to accept this direction and start implementing with and see
   what happes
   -

   DM: try to minimize risk, would be good to have data upfront to avoid
   having to do late changes
   -

   DJ: Sure, Ihopefully we’ll get some data in advance. We’ll also
   hopefully get implementation feedback sooner.
   -

   RC: Does the direction we are talking about, contrain the developer?
   -

   CW: …. In between the graphics work, you couldn’t do blit and compute.
   -

   RC: Does that restriction come from Metal? Would it have to detect this
   case and manually create some fences to make it look serial.
   -

   CW: This restriction is also a benefit to Vulkan.



RESOLUTION: One command buffer type for everything. We prevent compute and
copy work from happening within graphics work.
Queues

   -

   CW: We don’t have updates for investigations on pipeline states or
   queues.
   -

   JG: I have something on queues. Where should I dump it?
   -

   CW: In a github issue. gpuweb/gpuweb
   -

   JG: I just posted details to this:
   https://github.com/gpuweb/gpuweb/issues/22
   -

   JG: I got a bit into the woods discussing fences and queues. My
   understanding from last week of the D3D command queues was incorrect.
   -

   JG: vulkan and d3d have very similar types of queues. Vulkan queues are
   created up front, but d3d can be created on the fly.
   -

   JG: Metal can create them on the fly too.
   -

   JG: I provided some examples.
   -

   JG: As far as queues are concerned, we can easily implement the Vulkan /
   D3D semantics on Metal by not exposing extra queues
   -

   CW: So
   -

   JG: D3D/VK allow you to create new queues, assume Metal handles multiple
   queues in the back.
   -

   BC: In Metal, is there a model where concurrency is supported by
   creating multiple Metal contexts?
   -

   JG: You can create multiple queues in Metal but there are all “Direct”
   queues.
   -

   DJ: Specialization happens at the COmmand Encoders, not the Queues.
   -

   CW: I think this is similar to OpenGL. A system global queue where
   everything gets interleaved. Is it the same for Metal?
   -

   JG: You can have metal dependency chains between queues. I think this is
   new to Metal 2.
   -

   DM: I propose we take advantage of what the Apple driver might be doing
   underneath. Don’t expose raw queues directly, but have the API expose
   queues of a particular type. This way the user knows they are getting the
   optimisation.
   -

   CW: Do we want to have multiple queues?
   -

   DM: Not for the MVP. But eventually?
   -

   DM: I vote for deferring.
   -

   CW: Implementing multiple queues will be difficult, and confuse the API
   -

   DM: Isn’t it an implementation detail?
   -

   CW: Specifying validation is going to be hard.
   -

   JG: I think it is “just graph traversal”. It might be hard, but it could
   be straight-forward.
   -

   JG: Maybe multiple queues don’t need to be part of the MVP. A single
   queue would be ok to get triangles, but not as a proof of concept for a
   future API. We’ll need parallel command generation eventually, and it might
   be difficult with only one queue.
   -

   CW: In our prototype you can create multiple queues, but it really is a
   single queue behind the scenes. I think a single queue in hte MVP allows
   parallel buffer creation, without being too limiting.
   -

   JG: Problem is that it wouldn’t force us to do inter-queue sync correct.
   Believe this will be an important part of the shape of the future API.
   -

   DM: I agree.
   -

   RC: Can’t we have it so you can create multiple versions of this
   singular type?
   -

   JG: That’s true, but the specialised queues types don’t add much more
   overhead.
   -

   CW: Consensus is that it is ok to expose a direct queue on all APIs,
   because it should be efficient. If we decide on multiple queues, the API
   could say they have async queues for copy, even if they don’t really have
   one.
   -

   JG: I guess that’s fine if it helps Metal, but don’t think it does.
   -

   DM: Concern about what the user code will do. If we don’t expose
   Compute-Only queue on Metal, then it would be great if the app used it
   because it would be only one encoder.



   -

   CW: This is getting a bit too detailed. Let’s investigate more and
   discuss next week.
   -

   CW: Anything else in the last 3 minutes?
   -

   JG: Nope. I have some edits to make.

Agenda for next meeting

   -

   Things we didn’t talk about
   -

      Pipeline state
      -

      Renderpasses / Render targets
      -

   Get back on the Queue investigation
   -

   Administrative: F2F following discussion on the mailing list.