Skip to content

Minutes 2022 08 10

Jump to bottom
Corentin Wallez edited this page Aug 16, 2022 · 1 revision

GPU Web 2022-08-10

Chair: CW

Scribe: Ken, Kai

Location: Google Meet

Tentative agenda

  • Administrivia
  • CTS Update
  • “Tacit Resolution” Queue
  • Specify that texture_external sampling functions clamp coords to [0, 1] #2766
  • Expose the buffer state as an attribute #3014
  • Object labels require client-shared state #3263
  • GPUBuffers shouldn't have to accumulate a list of mapAsync promises to reject #3271
  • Lower the max binding index in createBindGroupLayout #3279
  • Agenda for next meeting

Attendance

  • Google
    • Austin Eng
    • Brandon Jones
    • Corentin Wallez
    • Kai Ninomiya
    • Ken Russell
  • Microsoft
    • Jesse Natalie
    • Rafael Cintron
  • Mozilla
    • Jim Blandy
    • Kelsey Gilbert

Administrivia

  • CW: Will send out an email about the editor nomination results
    • API: Kai, Brandon, Myles
    • WGSL: David, Oguz, Alan
  • CW: Pressure to finish the spec (though everyone already agrees)
    • Chromium would love to ship this year
    • Firefox said something similar?
    • JB: will enable in Nightly this year. Don't expect to enable it in Release until 2023.
      • Disabled for anyone on Beta/Stable channels. Nightly's a smaller population in Firefox. Tens or hundreds of thousands at most.
    • KN: assume you would still like the spec to not be changing by that point. :)
    • JB: (vigorous nodding)
  • CW: let's try to finish the spec - or get it in shape where it's done, even if there are bugs.
  • JB: right now, are we finding out sharp edges in teh API based on implementation experience? As long as we can avoid expanding scope of spec, that's good. But if there's something that can be done differently based on implementation experience,
  • CW: yes but we've been doing that for 5 years now.
  • JB: right now we're still finishing the impl. I expect to have comments based on impl outputs.
  • CW: worrisome - we can have feedback on impl experience forever. How do we say - now it's enough feedback? Or maybe have to do a breaking change later? That's the scary part. WebGPU is certainly hard to implement. Our impl experience - everything's implementable, but it's non-trivial.
  • JB: isn't it the case that the spec can't be finalized until there are 2 impls?
  • CW: right now we're in Working Draft phase. Doesn't even have to be implemented. Candidate Recommendation - it's a signal that it's up for wide implementability. Recommendation - set in stone.
  • A lot of specs are shipped in multiple browsers without even going to CR phase. There's the process, and what happens in practice. WDs are specs, people implement them and consider them specs.
  • BJ: what you're thinking of Jim - best to have 2 impls before you get to CR. But there's nothing to say that you can't ship before that. Pretty much everything ships before CR. My understanding - W3C reps are annoyed that some specs ship and don't push for CR. We can get to a shipping point before that. Not any step in the W3C process that says "here's where you ship".
  • JB: was misunderstanding -
  • …
  • JB: at Moz we still have a way to go implementing. Intend to bring feedback as we finish that up. If we find complex things not valuable to users - we'll continue to bring that feedback.
  • CW: understood, makes sense. Chrome would also like to be able to ship WebGPU; Safari's not close. When's a good time to ship, when spec won't change wildly and we won't break developers' code?
  • JB: when question is a date.
  • CW: it could be a condition. WebGPU works today - people are using it. Spec's high quality, people love it. People not complaining about ergonomics of language - it just works.
  • JB: condition I'd like - or Moz would like - is our impl is caught up to the spec today, and we've had a chance to give feedback on that process. That'd be fine for us.
  • CW: that's scary - mid-2023?
  • JB: don't think so.
  • KG: I wouldn't agree with that.
  • BJ: so what do you feel the timeline is?
  • KG: later this year.
  • JB: we're doing everything we can to get caught up within 2022.
  • KG: we know you want us to say, it's ready, let's ship it.
  • CW: API spec's been in a shippable state for a long time. WGSL spec caught up in the past couple of months.
  • JB: one impl's in a shippable state.
  • KG: we're still in the feedback phase.
  • BJ: we're talking about things in terms of, we'd like to ship this year. You're saying, we'd like to catch up with the spec as it is today. Both of these - we need to stop making large scale spec changes. Even if Moz isn't coming at it from the POV of shipping within N months - you still need the spec to stop changing. As little of a moving target as possible. Trying to drive towards - clamp down on the number of large scale spec changes. Always wiggle room for bug fixes, verbiage tweaks. Some things Chrome does today that aren't spec compliant. But in general we don't want to - for example - restructure the entire error handling for some future goal of multithreading, if we can avoid it.
  • JB: scale of changes I envision - not things like separating Z indices from texture array indices. Major API change, arguably usability, but a big change. Not the kind of thing we're going to come back with. Changes to the way mapAsync errors - details of ordering & when Promise rejection happens - for people using the API in the expected way, just not observable. But can make significant simplifications. Kai's changes to mapAsync's explanation - probably not unobservable. That's the kind of change I expect to see forward. Not changing programming model. Daily user wouldn't see it as a disruption of how they use the API. Moz has no desire to make major spec changes. Non-moving target - totally fine with us. We will have feedback though, and would like to bring that feedback. We're in this for the long haul. Customers may be pushing for 2023H1 - but the API will be out there for a decade, wouldn't like to say Moz can't improve the spec based on our experiences, based on a 6 mo difference.
  • KG: hard to discuss generalities. One reason why we're resisting the call to stop doing these changes is that we want to come back with changes to do. I agree that we want to slow down the rate of change. But don't agree we should stop making changes. The general philosophy agreement.
  • JB: also the premise - these changes will be implementation issues. Easy for us but hard for your impl? A good reason to not make the spec change. Don't think we should be worrying you too much. If there are successful impls that would be inconvenienced by a change - probably not a good change. Don't see it'll be a big impact.
  • CW: reassuring in a sense. Scope of changes you'd be coming up with could be done as breaking changes even if Chrome ships. If it's the error handling or something similar, probably ok to do a breaking change for early adopters. Right now, WebGPU's been started almost 6 years ago. Almost the longest running spec of web specs. All the browsers have been at the table the whole time. Today we're saying - let's not call the spec final, impl feedback has to come - tomorrow, Firefox is ready to ship, Chrome's ready to ship, Safari says, wait, we're just starting impl - do we wait another couple of years?
  • KG: the answer would be obviously no.
  • CW: trying to understand - there are a lot of specs pushed. Some specs Chromium's far ahead, sometimes it implements a spec and the spec comes later. Luckily that's not the case here. But I don't know if we can do a WebAssembly that ships at the same time
  • KG: I don't know if we can push this further in the recommendation track without more impls. Hard requirements? Hard to say. We decide as a WG, and that includes having quorum and making that call. Have to ask the members, are we ready to ship now? If not, what's blocking you?
  • JB: Corentin mentioned that all the browser vendors have been at the table, for a long time. Haven't you had a long enough chance to give that feedback already? Answer is - no. :) Our impl isn't done. Not about whether a certain period of time has elapsed - but rather do you have an impl that satisfies the criteria. Chrome's one of the best funded orgs in
  • KR: Without going too much into funding, thinking about spec criteria, we had a list of bugs triaged into v1 and post-v1. Let’s burn that down to zero, and if we consider larger change, we should probably let them sit as they are. There’s probably a way to implement something reasonable later. We can probably do these changes in a compat way in the future. Let’s get issues down to zero. Impl feedback is useful of course. We don’t go to rec without multiple impls. Looking at wording, I don’t think “canditate rec” is gated on mult implementations.
  • JB: yes. While impls settle - what I care about is that we can submit feedback while we're implementing
  • CW: call it feature freeze?
  • JB: feature freeze is something we totally agree with.
  • KG: with the understanding that we'll come to you with things that'll violate feature freeze. Hard to agree with generalities.
  • (discussion about
  • KG: we can agree that we don't want to make too many more changes. We agreed on V1/post-V1 split, being fairly aggressive about that on WGSL.
  • JB: fundamental issue - reason impl feedback's valuable is that it was unexpected. That's why making commitments is difficult.
  • CW: how does this work in other specs? e.g. Safari implements ServiceWorker?
  • KG: if you're super late to the game - your only recourse is, it would be great if we could make changes, but if it's shipped, we could make a new API. Sometimes the ship has sailed. Just tyring to not sail too early.
  • JB: in that scenario - suggests that the surprises will be rare. Right now only have 1 impl. Don't think surprises will be rare. 2 impls - pretty good indication that shortcomings will be minor.

CTS Update

“Tacit Resolution” Queue

  • Replace "out-of-memory" with the "internal" error type #3123
    • Was adding "operation" error type
    • Editors decided to rename "out of memory" with "something internal's gone wrong". Contextually, can determine this
    • KG: I would like to say "out of memory"
    • KN: mostly against the idea of "generic internal error" and "out of memory" sit next to each other. I'm fine with making a new error type for pipeline creation failure. So, validation, OOM, and pipeline creation failure. Would that be good?
    • BJ: I mostly lean toward not wanting an explosion of different error types. Narrowly scoped pipeline creation failure - if we find other areas of the spec where we find things can go wrong, would like a kind of error already spec'd. Understand spec'ing OOM - but what's the user's response? Get InternalError / OOM allocating a buffer - your response will probably be the same. Want to not overfit, but understand KG's point.
    • KN: what if we keep proposal, but add OOM? Internal errors, validation errors - but if you get internal error, we tell you whether it was OOM.
    • KG: I'd like to have distinction between OOM and something that was another internal eror. Your app could plausibly free up resources and try again. Fail 4 byte allocation? No recourse. 4 MB allocation? There is recourse.
    • KN: internal errors aren't any old thing. Spec will say the exact situations where they can be thrown. OOM on resource allocation, and failure to create a pipeline.
    • KG: I want some way to know OOM - internal error being an OOM is great.
    • BJ: I can iterate on the proposal for that.
    • KN: think that'd be fine.
    • KG: what's the rush?
    • KN: not a rush, we just have a lot of stuff to discuss.
    • KG: when it's in the tacit resolution queue, I'd expect quick up-and-down discussion.
    • KN: we can put this back on tacit resolution.
  • create*PipelineAsync prevents using the pipeline synchronously #3297
    • KN: long time ago Jasper filed creation about createRenderPipelineAsync being hard to use. Can't fire it in the background, and pick it up when we need it. Don't think we need to fix this for V1. Analyzed the problem so it'd be easier to discuss. Proposal for fixing this problem, not a proposed action. Since we dropped this - editors agreed we didn't need to make a change here. Decision made a long time ago - worry about this problem after V1, don't change the API. There's a reason for it, but not a strong reason for doing something right now. Tacit resolution proposal: say we won't change this for V1, and either move it to post-V1 or close it.
    • BJ: I'm good with that.
    • KG: (asked question, agreed)

Specify that texture_external sampling functions clamp coords to [0, 1] #2766

  • CW: Myles wants to be present for this, table until next week.

Expose the buffer state as an attribute #3014

  • CW: discussed last week?
  • KN: yes. Got hung up on multithreading model. Think we can separate that from this discussion. There's a question - map on one thread, what does state look like on the other thread? Don't have to answer that right now. Unmapped, pending and mapped state. No problem in single threading. Multithreading In the future - can decide whether that state's thread-local, etc. Think the 3 states work now, and in the future.
  • KN: was also discussion about mapping multiple ranges, which makes this perhaps not make sense. But doesn't prevent us from making the change now. If you do that you opt into it, and can opt into having a fourth state.
  • JB: idea was multiple methods, this map tolerates multiple ranges, or doesn't?
  • KN: yes. Might opt in by calling mapAsync multiple times. An error right now.
  • CW: mapping multiple ranges, from a while ago - difficulty is dynamic offset in bind groups. Dynamic offsets => have to look into BindGroup for the offset, not just the buffer. Mutli-map a buffer at creation time - can disallow dynamic offsets. … Actually, this is mapping multiple ranges while different part of the buffer's in use - never mind.
  • KN: it's related though. Multiple views of buffer - can use the view in a map or queue operation.
  • JB: so the views must not overlap. That's when checks occur.
  • KN: yes. Not sure it'll look exactly like that.
  • BJ: all we need to determine - this change won't block us from moving forward with a feature like that.
  • KG: interesting that we've come back full circle, think we had this proposal a long time ago. But I'm for it.
  • KN: no strong view V1 vs. post-V1 - but easy to implement. If we like it, we should do it.
  • KG: let's take it. If Apple/Microsoft have no concerns.
  • RC: I'm fine with this.
  • CW: let's tacit resolution this for next week.

Object labels require client-shared state #3263

  • BJ: last time - main issue, Rafael pointed out changing the label for something reused over time is good, so my option #5 shouldn't be considered. Loop back to this next week for multithreading discussion. MT aspect for this is the same as last issue. If we do something here now, will it block us from doing MT in the future? Don't think option #4 blocks this. setLabel from 2 threads - not convinced labeling is so important that having a race condition here will break anything. Think we can do this without blocking our MT progress. I suggest #4.
  • KG: attributes are getters/setters, can't have trivial behavior - so don't need functions
  • CW: in MT here - getter would be programmatic.
  • KG: getter's a custom function, can do crazy things.
  • KN: we can do #1. Can synchronize. I just don't think that's necessary. Don't think it's an issue to introduce high-precision timers. Don't think we need the synchronization.
  • KG: we could also say that the label's submitted when you queue submit the work. Don't think we need to do something for V1.
  • CW: same reasoning as previous issue. Looking at the spec as is - is there a problem we can't solve with multithreading? Think we can solve it - if objects are shared, we change the behavior. Probably will be fine as is.
  • KN: think we can leave it this way, do option #1, #2 or #3. Just feel it's unnecessary to lock ourselves in. Could do variant of option #4.
  • BJ: can't you just not define a getter for an attribute?
  • JB: just imagine people doing console logging. Just tell them what the label was.
  • KN: we can show the label in the console. Just not exposed to JS. When you console.log an object - we can show you extra stuff not accessible from JS. Promise pending? Can't tell that in JS, for example. We definitely would print that, it's important.
  • CW: conclusion here?
  • KN: everybody's fine with - leave it as is, figure out in the future. Maybe internally synchronized. OK with me, no strong feeling. Just should decide it explicitly.
  • CW: I think it's fair to discuss this. setLabel just removes the possibility of seeing the label. Worst case, multithreading scenarios - the label gets lost. MT in JS - it's wonky anyway. Think we should keep this as is.
  • BJ: I'm OK with that. Agnostic to it.

GPUBuffers shouldn't have to accumulate a list of mapAsync promises to reject #3271

Lower the max binding index in createBindGroupLayout #3279

  • CW: reason this was large - so developers had leeway to put bindings where they wanted. "512 ought to be enough for everybody."
  • KG: I've been thinking about suggesting 640. :)
  • CW: can we have it as an increasable limit?
  • KG: post-V1?
  • KN: I'd put the limit now if we're going to change it.
  • CW: OK. And spec should guarantee it's more than this plus this plus that?

Agenda for next meeting

  • Specify that texture_external sampling functions clamp coords to [0, 1] #2766
  • GPUBuffers shouldn't have to accumulate a list of mapAsync promises to reject #3271
    • KN: would like to talk about this offline with Jim.
    • JB: yes, interested in sorting this out. Maybe tomorrow?
    • KN: sounds good.
  • Colorspace conversions for GPUExternalTexture are arbitrarily complex #3293
  • Frame advancement of canvases that aren't visible #3295
  • Impl pain points, etc.
  • Buffer state validation in unmap() is unnecessary #3251
  • maxColorAttachments not sufficient? #2965
Clone this wiki locally