Minutes 2018 03 07

GPU Web 2018-03-07

Chair: Corentin

Scribe: Corentin & Kai

Location: Google Hangout

Minutes from last meeting

TL;DR

• CLA almost ready!
• There will be a meeting 03-21
• JG’s client buffer proposal (rendered Markdown)
  • Every buffer has a shadow copy for cross-process implementations. Only possible to map the whole buffer. Synchronization validation is done through the application observing the status of fences.
  • Concern that the proposal requires eagerly copying from actual buffer to shadow copy. Discussion about the application signal “intent” to read by transitioning to “map read usage”.
  • Debate on having promises only on fences (simpler) or also on buffers for mapping (closer cause-to-effect).
  • AI: CW to open issues about different dimensions of buffer mapping.
  • AI: JG to finish proposal

Tentative agenda

• Client side buffers
• Agenda for next meeting

Attendance

• Apple
  • Dean Jackson
  • Myles C. Maxfield
• Google
  • Corentin Wallez
  • James Darpinian
  • Kai Ninomiya
  • Ken Russell
• Microsoft
  • Chas Boyd
  • Rafael Cintron
• Mozilla
  • Dzmitry Malyshau
  • Jeff Gilbert
  • Markus Siglreithmaier

Admin

• DJ: Will meet with Apple legal about the CLA
• CW: Our lawyers said “we should reach an agreement in the coming days”
• DJ: Will check with Apple legal about the SPIR-V adopter program
• RC: Brought up that the adopter’s program for SPIR-V isn’t required because that’s our lawyers told us.
• KN: Changes to the SPIR-V spec should be bugs, everything else should be done as extensions.
• DJ: It’s up to every participant in WebGPU whether to become a SPIR-V adopter
• DJ: is still waiting for a response on the topic of a second mailing list. We get 5 by default, need to put in request to create new ones.
• CW: Should we cancel the meeting during GDC? Google folks will be there.
  • Others: won’t be at GDC.
  • CW: So we’ll have the meeting but without Google.

Client side buffers

WIP PR by JG: https://github.com/gpuweb/gpuweb/pull/50 (rendered markdown link)

• JG: Look like traditional APIs, immediate map and unmap
• JG: Follows the WebGL model. The difference is that mapping is disabled if it would incur a stall.
• JG: Map read for cross process: every mappable buffer has a shadow buffer shmem. Know things are done when a fence is passed, simple concept for single queue, and bit more complex for multi-queue. Could reject the map if the client didn’t observe that the commands passed by querying the fence. Once observed, the buffer is allowed to be mapped, this way under the hood the implementation can see that the buffer was modified, copy the modified parts over to shmem and voila.
• JG: Similar for map write, but the guarantee is that there are no read nor writes on the buffer. Depending on how you want the write to happen it could map discard. Unmap is an async command that goes over the IPC boundary, then the server can map the GPU buffer, copy the data and unmap it.
• MM: Didn’t follow everything. Also seems incompatible with the Google proposal so we need to pick one.
• CW: Incompatible parts of the proposal is more the synchronization part than the map a whole buffer vs. parts of it.
• MM: Read Google’s proposal we can talk about it more.
• RC: What’s the motivation for the proposal?
• JG: The API is simpler, implementation just as complex.
• DM: Like that it uses fences instead of introducing a new promise-like object. Idea is that there’s a shmem buffer such that mapping is instant if ready and otherwise invalid. One concern is that we do more readbacks and copies behind the user’s back.
• JG: The extra copies are only done if the buffer is map read usage, so if you want to write data in a buffer many times and read from it occasionnally then you have a small staging buffer for the occasional readback.
• DM: Would need a best practice to only write to a map read buffer
• CW: Found the three proposals:
  • Jeff’s proposal
  • Our proposal
  • (3) Jeff’s proposal but not requiring the shadow copy but has race conditions.
• JG: Second two are closer than you think. The guarantees can prevent you from getting into races.
• CW: I see. The difference between (3) and your proposal is that, in your proposal, if you don’t observe the fence, you aren’t allowed to map.
• JG: Down the road Vulkan can map buffer cross process.
• KN: Your proposal is almost the same as ours. Yours is “fence”, ours is “Promise”.
• JG: They are equivalent if your treat copying into a readable buffer as an intent to read from it. The browser eagerly copies into the shmem.
• CW: Basically three dimensions to the problems:
  • Poll, vs. promise/callback
  • Eager copy into shmem, vs. application gives intent to read.
  • Map only whole buffer, vs. map sub sections of it.
• JG: Things don’t have to be super eager, you could deduce the intent to read from the “usage transition”.
• DM: How about doing copies on fence checks. It kinda signals intent.
• KN: Problematic because you’d have to check the fence once to signal intent and a second time to have the fence tell you you can map the buffer.
• KN: Makes more sense to signal using a transition to Map usage, then fence to check when the transition is complete.
• CW:
• DM: Can flush at the end of every queue submit that writes to a readback buffer. See how the transition could be used but doesn’t seem necessary.
• JG: The usage transition makes an async and explicit migration. Wouldn’t get that much overcopying if we do copies eagerly when fences complete. Find explicit usage migration attractive, need to investigate more.
• KN: The explicit transition is what our map operation does, but you can also specify a range.
• JG: Think it is simpler if you removed the possibility to remove sub-ranges. Easier to do dependency analysis on whole buffer vs. sub ranges.
• CW: Let’s talk about dimensions independently, how about poll vs. promise.
• JG: <something about one being implementable with the other with promises on fences>
• <Debate whether it is useful for fence to be made via promises>
• JG: Relation to buffer mapping is that you can do async upload/download with JG’s proposal if you can have promises for fences.
• CW: Think that promise on the buffer much easier to use for an application
• MM: Consider the simple compute workload thing. The application doesn’t want to continually poll the fence.
• JG: That’s why you’d have something that can create a promise from a fence.
• KN: Benefit to turn a map/query pollable interface in a promise is that it makes latency significantly better at least in Chrome.
• JG: Benefit to have the sync promise on sync object is it makes the API simpler.
• CW: Agree it’s simpler since there’s only one place where callbacks come in. But it makes it harder to understand because cause (buffer write) is conceptually far away from effect (fence signaled).
• MM: Having less API calls doesn’t make the API simpler.
• KN: Pulling the effect closer to the cause makes the API simpler.
• MM: If it’s not obvious which things get completed by a fence, devs have more risk to ask for something before it is done. If things are more abstract it makes things harder to reason about for the devs.
• CW: Think this argument (MM/KN) is compelling.
• JG: Worried the explosion of fences makes stuff more complex for the application instead of having one fence and promise for a bunch of operations.
• KN: But Promise.all.
• JG: Complexity of aggregating them.
• <Debate about who the API is targeted to how difficult it is to use>.
  • KN: One use case is doing a bunch of math using GPU compute and doesn’t have to be hard.
  • MM: Would like the API we’re making to be usable in all situation that WebGL is used now (and WebGPU can run).
  • CW: If you can do WebGL and WebGPU then WebGPU shouldn’t be more complicated to use WebGPU.
  • <…>

Action items

• AI: JG finish writing his proposal and send it out
• AI: Google Github issues about the three dimensions of buffer mapping

Agenda for next meeting

• CW: Take a break and talk about another Big Question?
• WebWorkers
• Memory barriers if there’s time, just to see how it goes.