Skip to content

Minutes 2022 04 20

Jump to bottom
Corentin Wallez edited this page Apr 26, 2022 · 1 revision

GPU Web 2022-04-20

Chair: CW

Scribe: Ken / others

Location: Google Meet

Tentative agenda

  • Administrivia
  • CTS Update
  • “Tacit Resolution” Queue
  • Cannot upload/download to UMA storage buffer without an unnecessary copy and unnecessary memory use #2388
  • GPUBuffer.mapAsync is overly pessimistic #2646
  • Concerns around error label and message #2633
  • Shader stage input-output subsetting rules #2038
  • Agenda for next meeting

Attendance

  • Apple
    • Myles C. Maxfield
  • Google
    • Austin Eng
    • Brandon Jones
    • Corentin Wallez
    • Dan Sinclair
    • Ken Russell
    • Loko Kung
  • Microsoft
    • Jesse Natalie
  • Mozilla
    • Jim Blandy
    • Kelsey Gilbert
  • Unity
    • Brendan Duncan
  • Mehmet Oguz Derin
  • Michael Shannon

Administrivia

  • CW: Working on burning down toward V1 milestone
  • Currently, have 76 V1 API issues and 91 WGSL V1 issues
  • A chunk, can defer some…but need to triage
  • Post-V1-Polish milestone is for things we want, but don't care to do immediately as a group
    • Chromium for example - we care about WebCodecs, but not enough to block V1 on it
  • Let's try to use this milestone to drive down the issue list

CTS Update

  • Contributions from Intel
  • Memory barriers between texture storage, etc.
  • Finding bugs in our impl
  • Some contribs from Google this week - not that many
  • Please contribute! The CTS has been useful for us.
  • MM: it found 3 bugs in our impl in the last week or two!
  • CW: which entry points are you testing?
  • MM: resource creation, so far.

“Tacit Resolution” Queue

  • Item from last week; didn't receive a PR. No change.

Cannot upload/download to UMA storage buffer without an unnecessary copy and unnecessary memory use #2388

  • Nothing to discuss…
  • CW: What to do (if anything) for V1? Proposed an optional feature for V1 on the issue.
    • Happy to write that in the spec for V1; but also happy to postpone post-V1. Intel interested in for V1; Chrome interested in for Android too. At least Post-V1-Polish.
  • MM: I raised the issue…don't have a proposal; since CW's proposal was an extension I assumed it was post-V1. If needed by V1, still think nothing to discuss this week; need to decide whether this is an extension or not.
  • CW: we can do Post-V1-Polish stuff by V1. Just deciding whether it's non-optional and has to be supported.
  • MM: think there are 3 options. Including: add more functionality in the future; modify existing functionality (adding a new entry point) to support UMA.
  • CW: happy to do option (1), can open an issue and make a PR for spec text. Additional entry points - I think we need a proposal. Add'l functionality - Post-V1-Polish?
  • MM: add'l entry point wouldn't require a UMA machine. Would arrive post-V1, but wouldn't require specific hardware. Thought your extension would require the hardware.
  • CW: think we're in agreement that this is polish, not blocking V1?
  • MM: think it depends on whether there's a good proposal we like. If so, would like it to be in V1. Right now we're willing to agree with you, but might change our minds if something happens in the future.
  • KG: the future - isn't V1.
  • MM: understood.
  • KG: we can change it later.

GPUBuffer.mapAsync is overly pessimistic #2646

  • CW: was going to explain why you can't have proper ordering and have a less "pessimistic" mapAsync.
  • CW: written down in issue. Summarized the gist of it verbally. Can't guarantee Promise ordering in some situations.
  • MM: 2 points. 1, in our impl, the call to onSubmittedWorkDone and mapAsync go to the same place. Code you wrote in our impl wouldn't be able to have 2 orderings in the console logs.
  • KG: if they did would you care?
  • MM: 2, it's more imp't that mapAsync not block for unrelated work, that onSub… and mapAsync are strictly ordered.
  • KG: sounds good. If we agree on same result, it doesn't matter. They can be out of order.
  • MM: would be fine.
  • KG: say "Promise resolves at some time strictly after the work completes."
  • MM: also ok because - there are semantics associated with these - say they got reordered. Even if so, couldn't interact with mapped buffer in whatever one won the race. Have to wait for mapAsync, regardless of what order it's in.
  • CW: yes.
  • CW: do we still want some ordering guarantee? Could say that we guarantee mapAsync -> onSubmittedWorkDone, mapAsync will resolve first.
  • MM: depends on what impl can manage. Up to you.
  • CW: need to keep a queue of callbacks for both mapAsync and onSubmittedWorkDone, keeps the order of them, can be less pessimistic.
  • MM: that's legit. Calls to mapAsync are relatively ordered;
  • CW: don't' want to guarantee mapAsyncs are relatively ordered.
  • MM: agree, more like groups of mapAsyncs.
  • CW: why do we care about this when authors can do this themselves?
  • MM: how would an author do it themselves?
  • CW: before the submit that uses the buffer, they call mapAsync because they know they'll want the data. Difficult to see how the browser can do better, unless the browser splits Metal encoders.
  • MM: not worried about that case. Worried about if the author was using a library, the library does who knows what, and they want to enqueue work after the library enqueues its own work.
  • CW: I don't know if our impl will be able to do better, but the spec can change. Non-breaking change if we want to later add stricter ordering guarantees. Maybe fine for people.
  • CW: hard to define the equivalence class in the spec.
  • MM: prob next step - I should make a PR describing how I think it should work, then you all can review.
  • CW: if you want onSubmittedWorkDone to guarantee that all previous mapAsyncs are done…
  • MM: if it's implementable then we can spec that.

Concerns around error label and message #2633

  • CW: lot of discussions, from intl to "do we need these at all"?
  • CW: editorial issue - USVString? (USVString or undefined)? Should just decide something.
  • CW: issue about whether we want to expose these validation error messages.
  • MM: last week - said from app's point of view, they won't parse the text string. If we're displaying these messages in the console, what's the point of a JS API? Few different responses last week - e.g. about app telemetry. Another, don't remember.
  • BJ: ShaderToy/Codepen sites, want to facilitate live editing. Error handling goes along. There are ways to do that (gman@ pointed out). Running validation on server, compilation tools in Wasm, etc. Still nice to have these JS-visible.
  • KG: one use case you can imagine - debugging some XR thing, have headset on - want to see when errors pop up, know what they say. Want redirection to be able to see what's happening. Not just "this is a validation error". I wish we had this for WebGL. I would vote for this.
  • MM: I wouldn't vote against this - just something group would be aware of. I don't have a strong opinion about this.
  • BJ: nobody strongly against returning the strings in JS. Floated as a way of avoiding difficult intl work, if that's a sticking point for horiz review. Is that accurate?
  • MM: arg about not wanting these messages - don't think rationale is that we don't want to answer hard intl questions. If we return strings, we have to deal with intl. More, what are these for. If we think these need to be internationalized we can do that.
  • MOD (in chat): internationalization team just wants to say that if there are these human-readable messages, just have lang and dir fields next to them, and that's it
  • KG: what are lang/dir?
  • CW: language, direction.
  • MM: each message will have the same lang and dir. Shouldn't put them next to the field but have them global.
  • MOD: not guaranteed IMO.
  • MM: returning different languages based on errors?
  • MOD: same error might be returned in different languages based on browser.
  • CW: seems to be a separate topic we'll need to get to. Last week we got distracted on this issue, the shape of intl here. Let's talk about separately, in its own time.
  • KG: what do you propose? Split part of this into a separate discussion?
  • CW: saying - yes, expose messages to JS - and someone else to decide what to do with intl of the strings, proposals, links to things, best practices. Hard to discuss right now. Overloaded with a different discussion.
  • KG: OK. Web IDL thing - let's try to do the easier thing, and if people say we can't, we'll do the more complex thing.
  • MM: this issue had 3 pieces originally.
  • CW: do we need to return errors to js? fingerprinting, agree not a concern. I'm hearing, yes, we want these - or, not sure, whatever other people feel strongly about.
  • CW: Web IDL issue. KG said, someone should figure it out.
  • CW: 3rd issue - I don't remember what it was.
  • MM: GPUObjectBase.label. People thought that came from the browser.
  • BJ: was part of fingerprinting concern. Not a concern.
  • CW: let's try to close off this issue. BJ since you're editor, please create new issue for USVString undefined/null. Yes, error messages. Oguz (?) create issue for intl of these.
  • MOD: sounds great.

Shader stage input-output subsetting rules #2038

  • CW: old issue, maybe candidate for post-v1 polish.
  • CW: proposals are to loosen things.
  • MM: idea - pipeline of things connected to other things. attribs into VS; outputs into the FS; FS writing into textures. Each boundary is an interface. Can either require these match exactly, or allow the producer to produce more than what consumer consumes.
  • MM: think this is mostly technical, what can be represented in the APIs. Can compile shaders so these interfaces don't need to match?
  • CW: both Metal/Vulkan allow FS inputs to be subset of VS outputs.
  • MM: D3D12 has an ordering requirement.
  • JN: any inputs to later stage that are not system values needs to match in ordering the same subset from the previous stage. Inputting 3 attribs in PS coming from VS - need to be the first 3 attribs in the same order from VS>
  • MM: makes sense.
  • CW: all need to be present in FS?
  • JN: no. Can have outputs from earlier stage not in later stage.
  • MM: if consumer consumes 3rd attribute - it needs to consume the first 2 attribs too?
  • JN: yes. You can't skip attribs.
  • CW: assume float4 output 0, 1, 2. Want to use input 3 as float4 in frag shader - I need to declare 1, 2? Or want to use 2, don't need to declare 3?
  • JN: correct.
  • MM: think that makes sense.
  • CW: builtin values FS uses? SV_Position for example? Does position of SV_Position in input structure need to match its location in VS output structure?
  • JN: yes, if written by previous stage like SV_Position - assumed same order between stages. Is_FrontFace, for example, can be at the end.
  • MM: that's the trick - if producer produces 5 outputs and an SV_ value, and consumer wants middle output and SV_ value, consumer needs all values in their struct.
  • JN: correct. Well - doesn't need to be last - needs to be in same position on consumer side.
  • CW: ah we want to put it last because otherwise we have to declare it in FS.
  • MM: think we should adopt this rule from HLSL wholesale into WGSL. In the spirit of taking the intersection of API expressivity.
  • CW: back then - did we have input/output structures in WGSL? Think we did.
  • CW: given compilation model with pipelines - D3D12 has them - assuming you get DXIL, turned into LLVM IR, then optimized when creating graphics pipeline. Is there a reason it has to stay in the same order?
  • JN: good question. Predates my time here. Took the D3D10 rules & rolled them forward. D3D10 had separate compilation, had to match when bound to pipeline. Not sure we did thorough investigation of what could be removed.
  • CW: ideal - have Metal/Vulkan rules everywhere. Maybe yes, we take the D3D12 rules - but maybe D3D12 changes the rule in the future. Dawn would be fine lifting the rules for D3D systems at that point. Maybe FF is OK with this? Loosen the validation. Trying to get to the ideal state some day.
  • JN: understood. Surprised haven't heard this feedback before. Thinking, does seem restrictive, should revisit.
  • MM: you think ideal rules are more flexible than what we have now? What are the ideal rules?
  • CW: Metal/Vulkan. Later pipeline stages need to have inputs that are a subset of previous stages.
  • JN: can have holes.
  • MM: and they can be reordered.
  • MM: agree that's desirable. Seems like we have a resolution, up to editors to spec this. Not dealing with resources, not dealing with bindgroups. Attribs are one-dimensional; shader interfaces strictly ordered, etc., so not intractable.
  • CW: problem - in D3D you can put SV_Position wherever you want. If you use it in frag shader you still need to spec everything before/after it. Have to decide how this'll work in WGSL. Does it always go in the end? Have to specify everything in FS then.
  • MM: makes sense. We also have static use rules. Shouldn't rely on source order.
  • CW: also entry points take things as arguments.
  • JN: how it is in HLSL too.
  • CW: ordering between structures-in-structures, parameters, etc.?
  • JN: also packing rules where vectors can combine. Here, concerned about packing WGSL args to match lower-level D3D linkages - vec4s.
  • MM: sounds like we need to make technical proposal.
  • JN: makes sense to me.
  • CW: sounds like someone from Google will have to take this on.
  • CW: Jessie would you need an email with details to make a concrete D3D12 feature request?
  • JN: I can write one up myself, that's fine.

Agenda for next meeting

  • KG: if intl is V1 need to discuss.
    • CW: MOD can you investigate / propose for next week?
    • MOD: can do in the next few days.
  • CW: bunch of canvas discussions, hope can help drive them.
    • Lots of convos with annevk@, maybe from Chromium can come, someone from Firefox / WebKit?
    • KG: already here.
    • MM: trying to decide if I'm the right person. Maybe Dean is.
    • KG: we have an APAC in two weeks.
    • MM: let's do it there.
  • KR: difficult bugs?
    • CW: biggest ones are around canvas. Some impl discussions around what Myles found. GPUAdapter.name. Grab bag of random stuff. Some could be post-V1 polish. Exposing descriptors, size of container objects, reworking validation of viewport to be looser b/c of Metal, etc.
  • CW: I'll make agenda - please put your items at the end of these minutes here.
Clone this wiki locally