Minutes 2018 10 15

GPU Web 2018-10-15

Chair: Corentin

Scribe: Everyone

Location: Google Meet

TL;DR

• We’re tentatively planning to meet F2F in San Diego end of January.
• PR #99 extension validation
  • The spec should specify for each error if it is sync (exception) or async (callback)
  • Browser implementations have to be compatible under the “as-if” rule
• LGTM on PR 91 and 96
• Don’t care / discard, #97
  • 3 proposals on the issue, 1 and 3 are deterministic but differ on whether the application or the implementation do the clearing of resources. Proposal 2 has different behavior on desktop and mobile.
  • 1 vs. 3 also ties in with how we handle zeroing resources when they are created.
• Push constants
  • Suggestion to not restrict push constants and fallback to a uniform buffer if needed.
  • Concern that adding a uniform buffer would mess up pipeline layout / bindgroup layout.

Action Items

• CW to look into a meeting space in San Diego
• KN to address comments on PR 98, RC to review

Tentative agenda

• Command buffer submission model
• Extension validation
• Dont care / discard
• (stretch) push-constants
• (stretch) multi-queue
• Agenda for next meeting

Attendance

• Apple
  • Dean Jackson
  • Myles C. Maxfield
• Google
  • Austin Eng
  • Corentin Wallez
  • Dan Sinclair
  • James Darpinian
  • Kai Ninomiya
  • Ken Russell
• Microsoft
  • Chas Boyd
  • Rafael Cintron
• Mozilla
  • Dzmitry Malyshau
  • Jeff Gilbert
• Elviss Strazdiņš
• Mehmet Oguz Derin
• Timo de Kort

Admin/Misc

• CW: Should we try to meet in January in San Diego? (next to WebGL meeting)
• CW: I think it’s a good idea.
• KR: Close-ish to Bay Area
• RC: I’m ok with meeting.
• KR: Where can we meet?
• CW: Do we have a Google office in San Diego?
• KR: No.
• KN: Yes, we do.
• CW: Google will organise something, or look into it.
• KR: Currently WebGL is Monday PM and Tuesday AM. So WebGPU would work on Wednesday.
• CW: added pull request #96. to add Destroy() methods to Buffer/Texture. Seemed non-controversial, merged without review from everyone, needed.
  • MM / RC: good change.
  • RC: when does it really go away? Tracking references and destroying when all gone, or destroy eagerly and commands in flight fail?
  • CW: makes resource internally null without generating an error. Subsequent commands submitted cannot reference, but in-flight commands can.

Command buffer submission model

• CW: DM added this topic?
• DM: I needed to write a doc; have not done this yet.
• CW: let’s skip.

Extension validation

• KN: PR #99
• KN: summary: error cases in API can either be sync/async. We spec whether errors are sync (throws exception) or async (contagious internal nullability - CIN?)
• KN: guidelines are how we choose which error reporting model we choose on a case-by-case basis. Want things to look the same between extension not enabled vs. extension not supported by browser at all. Can throw exceptions if you try to call extension not enabled, or if browser doesn’t support it (attempting to call “undefined”, which is a JS error).
• KN: for simple validation on range of number argument, can / should choose to make this sync, but not if it’s dependent on state somewhere.
• KN: checks on service-side state - stuff that can’t be tracked client-side, like device loss or out-of-memory during allocation - must be async.
• KN: these are all guidelines for how to choose while writing the spec whether errors should be sync/async.
• DM: if user requests an extension and tries to use value from this extension on frontend, they won’t get a context so that can be sync, correct?
• KN: correct. If extension not enabled we should throw an exception.
• CW: proposal says we should do trivial validation client-side. (Arrays being same size, enum is one of values allowed by extension or core spec, etc., bounds checks.) Other validation should be deferred to service side.
• MM: every error will be marked sync/async. This is not just for extensions right?
• KN: correct, for all of API. But have to think about whether browser supports a given extension, and the failure modes if not.
• RC: will read PR today and give you answer by end of day.
• DM: if something’s not trivial to validate then server should validate it. What if client can do the validation and then provide proof-of-work to the server that it was done? Think it’ll provide benefit to the user.
• KN: implementations will have to be compatible. For any given error in the spec we have to define whether it’s sync or async. How we choose which way we go is in the spec.
• MM: you saying all should be sync?
• DM: no, thinking about: recording a render pass, client side records the whole pass, knows about transitions before/after pass, consistent usage, etc. Can capture many errors during recording, and send them to server.
• CW: sounds like “as-if” rule in APIs. Happens “as if” the validation happened at a certain point.
• MM: for example you gave, moving an error check from async to sync is fine. At the time the error is discovered it can be deferred. Problem is the other way, moving something from frontend to backend.
• DM: problem would be moving backend to frontend.
• JG: it’s “as-if” proposition. If validation done sync and it’s defined async, instead of throwing, use CIN to surface error.
• DM: I perfectly understand how it fits into deferred error rule. It’s better for the client to have the errors happen as early as possible.
• JG: this is like developer mode.
• CW: we really don’t want some browsers using CIN for command buffer creation and some using exceptions. Right now, they assume that if they don’t do something stupid with arguments, then they won’t get exceptions. Throwing exceptions unexpectedly may break applications.
• DM: fair. In error log, there’s probably some ordering. CPU timeline? GPU? etc.
• JG: do we have an error log?
• CW: yes, though it’s early. Callback called on every error.
• DM: is the order defined by the spec?
• CW: unclear. We can decide.
• JD: in developer mode, things may be serialized mode.
• MM: probably shouldn’t talk about developer mode; per-browser, not covered by spec.
• JG: agree. Also, WebGL’s validation is this CIN thing. But errors are surfaced ASAP, in the JS console. Not defined in any order. But for local debugging they work well.
• KN: yes. Those work well, and we could use that idea.
• DM: OK sounds good.
• RC: agreed that for each error in the spec, we decide whether it’s sync or async, and impls can’t decide which?
• CW: correct. Now we need to decide guidelines for whether errors are sync or async.
• KN: there’s a strong incentive to make more things async than we need to be.
• JG: we should default to making errors async.
• DM: current uses are enums that extensions can use, and functions provided? PR also talks about limits? During device creation you can get higher limits.
• CW: adapter tells you what maximum limits are. You have to explicitly enable higher limits to get them on your device.
• KN: limits on device are same as what you asked for.
• DM: OK, and at any given point we know what device you’re talking with?
• JG: you have to submit the descriptor to the device to create it.
• KN: could decide to make certain descriptor related things sync.
• CW: sounds like we mostly agree on the concept of this PR. Have to detail which errors are sync.
• JG: I’m fine merging this and fixing it.
• CW: would like to give RC chance to review.
• DM: CW’s comments have to be addressed as well.

Renaming attachment states

• https://github.com/gpuweb/gpuweb/pull/91
• KN / RC: LGTM
• MM: should we set up a process to know what can be merged so we don’t have to talk about them in the meeting?
• CW: would like one person from each browser to comment before merging.
• JG: I like discussing these in meetings. Don’t take very long.
• MM: that’s fine.

Provide the attachments state when starting a render pass

• https://github.com/gpuweb/gpuweb/pull/92
• RC: don’t think we need to add more things to a render pass for D3D.
• https://github.com/gpuweb/gpuweb/pull/92/commits/c44dc2e4b5784f2af9e06992f70788be8529d2b9
• CW: adds the format to the render pass descriptor, even though we already have it if we look inside the attachments.
• DM: doesn’t add the formats, adds the handle to the attachment state.
• CW: you want a precompiled renderpass attachment state? To reuse Vulkan renderpasses better?
• DM: yes. This is the core of the Vulkan Renderpass portability. Even though we may need to create a renderpass, we know all the pipelines are compatible with it.
• CW: ok, so, trying to encode attachment compatibility as pointer in pipeline so we can compare by pointer than by value?
• DM: maps better to Vulkan.
• DM: compatible render passes. Plus some stuff mutable that affects compatibility. Within this render pass, you can only use the pipelines created with this handle for attachment state. If we want to not do this, there’s some complications in the impl which I’ve tried to elaborate in the comments.
• CW: would like some more time to think about this. Had misunderstood the original pull request. Was also looking quickly at multisampling. In Vulkan, the pipeline might need to know which attachments are going to be resolved at the end of the renderpass, which is unfortunate, but could put this in the attachment state.
• MM: would also like more time.
• JG: let’s discuss next week.

Dont care / discard

• https://github.com/gpuweb/gpuweb/issues/97
• CW: have people read this?
• (no)
• CW: basically, every API with render passes has a way to not load data from memory at beginning, and not store to memory at the end. Need this for WebGPU because otherwise performance on mobile will be destroyed. This is a key API in Metal and Vulkan.
• CW: because these introduce undefined behavior it’s hard to spec them in a developer friendly way.
• CW: we can punt on these till next meeting so people can read about them.
• RC: I was able to understand proposal #1 but didn’t understand the issues.
• CW: prop #1: b/c not storing values introduces undefined behavior, when we say “don’t care” that’s like lazy clear. Same way we have lazy clears during initialization. On discrete non-tiler GPUs, have to do the clear. Might be more expensive than just storing/loading the data. (We would load data at beginning of pass, store at end, and additionally clear.)
• JG: why not just invalidate?
• CW: undefined values.
• JG: treat as if it’s cleared - hard for me to think about things that aren’t proposal 3.
• CW: #3 is lazy clear, but also force application to do it. (Check that they did it.)
• DM: thought we just validate and error out? Nothing lazy?
• CW: yes, correct.
• JG: proposal #3 enforces best non-undefined-values behavior. Forbid touching undefined values, but if you wanted to load previously invalidated resource, have to use clear op.
• CW: what if app wants to copy into part of that texture? You write data, so you’re clearing some undefined values, but not clearing the whole level?
• JG: is separate drawing part of render pass state?
• CW: maybe. Some APIs have it.
• JG: if we can only access whole levels it’s fine.
• CW: here you’d have a partially defined level.
• JG: not if you can’t decide which sub-rect you’re clearing. Could just forbid the case you describe.
• DM: forbid buffer-to-texture copies not in fully cleared state?
• JG: invalidation is borderline required.
• CW: question is, when rsrc created, should we lazy clear it for the app, or validate that app does all clearing / setting of pixel data before can use?
• JG: nicer to do the latter. Then app knows what’s happening.
• DM: good question. Shows how the issue transcends into what to do with resources. Scope of issue is greater than subject describes. Would prefer to let the user do the work and browser validates it.
• CW: would work. Should discuss more. I can make an issue about rsrc initialization and undefined values at beginning, and proposal of lazy clear for app, or making app do lazy clear themselves.
• DM: SGTM
• CW: please everyone look at this issue for next week. Difficult to get right but important for mobile platforms.
• KR: do any native APIs provide guarantees that if you invalidate, that you only see data from your device, or similar?
• MM: that wouldn’t be sufficient - at least on Metal, there’s a singleton device per process.
• RC: in D3D we do have per-process guarantees, but if you share the device you’ll get into troubles.
• JG: no trouble even if someone frees up 1G of memory and you get some of those pages?
• RC: correct; OS does zeroing.
• JD: Still don’t want undefined behavior even if no security issue.
• MM: proposal 2 - does it have different behaviors on desktop and mobile?
• CW: yes, it would. That’s why it says do this or that. Not pretty.
• KN: this is the only situation we have currently where if you develop on desktop it wouldn’t work on mobile.
• MM: that would be bad.
• JG: do we know desktop GPUs don’t do lazy clears? Clear is just setting a flag on a resource.
• CW: in explicit APIs the driver will clear the resource. Maybe you mean that in every GPU out there, there’s a flag next to each texture block saying “is this cleared”. Easy compression win.

Push Constants

• MM: posted a big comment about an hour ago. In general, proposal is pretty good, and I see the use case for it. Modification I proposed: let API specify as many of these push constants as you want, but impl can use buffers behind the scenes.
  • 1. If we want to pick a limit small enough for each API it’ll be really small. And for D3D maybe there isn’t a limit b/c storage shared btwen descriptor tables.
  • 2. App not using push constants should get their benefits. Letting app use them as impl detail of a particular call would make apps faster.
• MM: Proposal:
  • Keep this proposal - you can upload constant data for use in shader.
  • Allow impl to fall back to using buffers.
• CW: would like to point out that on Vulkan, there’s a guaranteed limit of 4 descriptor sets, not more. So it’s not like WebGPU can have arbitrary amounts of descriptor sets in the pipeline layout.
• MM: mentioned this in the comment. 2 ways. 1) Impose things on WebGPU programmer. 2) Shuffle descriptors around and collect them in 1 or 2 tables for the developer.
  • Logic: if we’re shuffling around descriptors, then to have push constants also done by that process is not a large amount of extra work.
• JG: sort of like the idea of “soft limits”, and having normative text saying that under certain limits, they should be push constants.
• CW: just worried that doing this requires us to shuffle things around with bind group layouts in Vulkan, so that we always have one free bind group for push constant buffers.
• MM: at time you compile the pipeline you know both the size of push constants and the bind group layouts so you can do the merging as necessary.
• DM: don’t know this at DescriptorSet / bind group layout creation.
• MM: maybe I don’t know Vulkan API well enough.
• DM: in Vk you create # of descriptor set layouts. When you create pipeline layout you pass multiple descriptor set layouts. Can’t create them when user says to, later.
• JG: if we surface what users will call later (the layouts), early, but don’t have a strong limit on size of layouts, is that viable?
• CW: not sure I got that. Issue is that bind group layout, used during bind group creation, have to be the same - at least - by value. If we don’t do this and start merging things, we won’t be able to create Vk bindgroups when WebGPU bindgroup is created, b/c we’ll need to know if it needs to be merged with another one.
• DM: I’d like to spend more time reading Myles’ comment.
• RC: do we know whether all the APIs have a fallback? Like root constant buffer in D3D?
• CW: in Vk there are only root constants or root descriptor tables. If we want to have a fallback uniform buffer then it’ll have to be in a root descriptor table. Harder because we’ll need a layout for this, etc.
• CW: need a lexicon of what’s called what in different APIs.

TPAC discussion

• RC: someone says there’ll be a WebGPU CG meeting at TPAC? What’s the agenda?
• CW: at TPAC, MM and I will be there, and we’ll make a WebGPU breakout session. A formalized corridor conversation at TPAC, where we talk with everyone interested in it. Just outreach to the rest of W3C.
• MM: focus is to talk externally with other W3C members.
• JG: good luck.
• CW: thanks.

Agenda for next meeting

• #92
• Push constants
• Discard and don’t care
• Multi-queue