Skip to content

Minutes 2019 02 25

Jump to bottom
Corentin Wallez edited this page Jan 4, 2022 · 1 revision

GPU Web 2019-02-25

Chair: Corentin

Scribe: Ken

Location: Google Meet

TL;DR

  • Planning for the next F2F meetings:
    • Something mid-May in the Bay area?
    • The WebGL WG will likely meeting in New Orleans in September, do something there too?
  • Error handling, #198 no concerns but folks will take a last look.
  • PR Burndown:
    • #131: canvas.getContext(“gpupresent”) is what will be used to create a GPUCanvasContext
    • #218 splitting the rasterization state a bit further
      • No strong opinion, DM + JG to discuss and merge this
    • #217 Moving gpu from window to navigator
      • Consensus to do this.
    • #211 depth-stencil texture formats:
      • Merge it, we’ll have a discussion about format and capabilities in the future
    • Agreement to not use fluent syntax for encoders
    • Consensus to use u64 where it makes sense (like buffer sizes), and not introduce type aliases like “GPUBindingIndex = u32”

Tentative agenda

  • #188 WHLSL and binding model
  • More error handling
  • Vertex and input descriptor changes
  • PR Burndown
  • Agenda for next meeting

Attendance

  • Apple
    • Dean Jackson
    • Justin Fan
  • Google
    • Austin Eng
    • Corentin Wallez
    • James Darpinian
    • Kai Ninomiya
    • Ken Russell
    • Shrek Shao
  • Microsoft
    • Chas Boyd
    • Jungkee Song
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert

Administrative

  • DJ: Need plan for the next F2F
  • DM: Khronos meets in New Orleans in September
  • DJ: And WebGL will likely attend.
  • KN: Always possible to find a private venue, can be expensive.
  • CW: only thing we need for WebGPU is network. Might be possible to work something out for New Orleans.
  • DJ: I’m sure Apple has a store in New Orleans. Not sure if they have conference or meeting rooms.
  • JS: I think we should aim to have a WebGPU meeting before September.
  • CW: I’ll be in Bay Area beginning of May - how about 2nd week of May? Last F2F was January, May would be ~4 months, pretty good cadence.
  • KN: that’s roughly Khronos’ F2F. Sounds good.
  • CW: what about May ~13-17?

#188 WHLSL and binding model

  • Skipping because Myles is absent

Vertex and input descriptor changes

  • Also skipping

More error handling

  • KN: #215. Probably needs new revision based on comments.
  • KN: #198. Fatal error handling. Updated with an investigation and updated PR to provide a Promise which resolves when the device is lost. Device only goes from “not lost” -> “lost” once. Avoids weirdness about registering event handler at the right time. Gives you the right signal in order to recover. Got some feedback on Github that people are in favor of that idea. More feedback?
  • RC: haven’t had a chance to review either completely. What I skimmed over on #198 seems in good shape. Would like more time with both.
  • CW: idea for #198 right now: when you create Device, get Promise of that device.
  • KN: there was a potential problem with event handlers that’s not there with Promises. No matter how long since Promise resolved, if you call .then() on it, you always get that called.
  • CW: that sounds even better. No concern right now but people want a chance to look through it a bit more?
  • RC: yes please.
  • JG: no other feedback right now.

PR Burndown

  • CW: #131 DOMstring to pass to HTMLCanvas.getContext()
    • CW: I sort of forced the issue with gpupresent, is everyone OK with this?
    • RC: fine with me.
  • CW: #218 splitting the rasterization a bit further.
    • DM: we have 3 fields all about depth bias. For us it would be more convenient to have them in a separate struct. I think for end users as well.
    • JG: what makes it better for us?
    • DM: if you write for Rust you don’t have default values for fields but you can have default structure constructors.
    • CW: so with good defaults it’s nicer.
    • DM: yes.
    • JG: why isn’t that true for having it inlined?
    • DM: if it’s inlined there’s not a good default constructor for the whole thing. Like frontface. It’s just not ergonomic. If that bias comes from some other source of knowledge they’d want to pass it over in some form.
    • JG: just seems like unnecessary nesting.
    • DM: we do have nesting of dictionaries.
    • JG: not a goal to nest as deeply as possible.
    • CW: with good defaults in JS, keeping it as a dictionary and inlining it is about equivalent.
    • KN: I don’t care.
    • JG: I don’t care much but think the defaults should be inlined. Think generally having more nesting will make things worse for users.
    • RC: no strong opinion. Wanted to ask: how does nesting / not nesting affect the defaults?
    • DM: affects them when using from Rust. Not really from JS.
    • JG: is that a compelling argument?
    • DM: perhaps
    • CW: splitting into depthBias.slopeOffset / slopeScale does group things together.
    • JG: I don’t care a lot but I think it’s more ergonomic to not split this off. If noone cares then I think the default behavior should be don’t merge it.
    • DM: there are objective reasons for doing this for Rust; but in JS, you’d be able to provide a dictionary with fewer named fields.
    • JG: you’re adding more structures.
    • KR: Looking at the design of native APIs, there was a lot of discussion whether to split sub-state in their own structures. Make things more fine grained like them?
    • DM: In Metal depth bias is together and separate from the rest?
    • JG: can you elaborate why this is better for Rust?
    • DM: it’s honestly a bit out of scope for the working group.
    • CW: OK. Let’s not split this off. People generally don’t have to touch this. They can just skip it.
    • JG: you can already get auto-completion, etc. by giving all of the depth bias fields defaults. How does having it in a separate object make it easier?
    • CW: for beginners, if it’s a sub-Descriptor rather than 3 members in the same descriptor, it has less cognitive overload.
    • JG: splitting things into sub-structures makes traversing the documentation harder. Slightly easier if we have 3 things inlined vs. separate structures. But other people don’t care so let’s merge it.
    • CW: after the snapshot we can have Twitter polls.
    • JG: it will never be changed. Let’s merge it, but keep this in mind. I don’t think nesting makes things easier for users.
    • DM: I’ll try to talk with you offline about the Rust difficulties.
    • CW: DM could you please have the discussion and merge this?
    • DM: will do.
  • #217 Moving gpu from window to navigator
    • KN: not sure this is the best way to do this but it’s similar to WebUSB and WebBluetooth.
    • JG: early on, one of the prototypes had this on navigator rather than window.
    • KN: “window” is in the global scope, navigator is in an object in the global scope. Basically like “gpu” vs. “navigator.gpu”
    • JS: using navigator for API container is more conventional. Most other APIs put their manager objects on the navigator. window is more a browser window in addition to being the global namespace. We like moving it to navigator.
    • RC: sounds fine to me.
    • DM: the fewer globals, the better.
    • DJ: does Worker have navigator?
    • KN: yes.
    • CW: there’s even WorkerNavigator in Kai’s pull request.
    • KN: I also copied this from WebUSB.
  • #211 depth-stencil texture formats
    • JF: I checked all the APIs for these 4 depth-stencil formats. DX12 doesn’t support STENCIL8, but aside from that sounds straightforward.
    • CW: sounds straightforward. Some are optional on some APIs. In texture format compatibility investigation…
    • JF: so even if it’s on the format list it might not be universally supported?
    • CW: right. I think DEPTH_32F_STENCIL_8 is the only universal format. Need to do thorough investigation of supported formats. Can prune lists at that time. Can add these as is in the meantime.
    • RC: when we do this investigation, we want to feed in the format to the API and ask, “is this supported”? If it doesn’t even show in the list for D3D we shouldn’t add it. We should also have the web developer to have to ask what’s supported on the current hardware. Similar to compressed texture extensions.
    • DM: thought we were going to be more coarse-grained and not expose as much of a surface to query because of fingerprinting. Compressed textures make sense - have big groups of things exposed - but individual texture formats and their capabilities is a bit detailed.
    • CW: concerned about portability aspect as well.
    • JG: I don’t think there’s a way around it. In WebGL we have this issue where FP targets might not be render targets. If someone assumes they are renderable they’re going to write bad code anyways. We can try to tell devs which formats aren’t universally supported, but that should be a different PR / issue.
    • KN: probably should be capabilities on the device. Don’t expose them universally for portability.
    • CW: if everyone’s OK with this PR let’s merge it. Have to have larger discussion about formats / capabilities.
    • JG: to clarify: I think we should not care about fingerprinting for these because we’re going to expose what the actual device is. It’s a portability concern, not a fingerprinting concern.
    • KN: I think it’s more of a portability rather than fingerprinting concern.
    • DM: do we have a non-fully-qualified-device name exposed?
    • JG: yes. If you want a “resistFingerprinting” option in FF, you’d spit out some fake device and restrict all capabilities to a subset.
  • #216
    • KN: Dean since you opened the debug label thing is there a reason you didn’t put debug labels on all of the objects?
    • DJ: no reason.
    • CW: still think these should be on the descriptor.
    • KN: at least if we have this we’ll have a single place to put all of the labels.
    • CW: Mads asked us explicitly to be able to set these after the fact. But we shouldn’t encourage them. Having them set at creation time but settable later via function is better.
    • RC: how is that better than an attribute?
    • CW: it’s write-only. Functionally equivalent instead of reading back.
    • DJ: I doubt that people would store the label on the GPU side. Changing the label might be almost a zero-effort thing.
    • CW: in Chrome we’d need to store it on both sides for example.
    • RC: when you have a texture cache changing what things are used for, want to update this dynamically. There’s a case to be made for setting it afterward.
    • JG: we can merge this particular pull request?
    • RC: yes.
    • KN: merging.
  • CW: anything else we can look at? Probably want Myles’ input on others.
  • CW: one thing: in snapshot tracker: do we want fluent syntax on command buffer encoders? So .setPipeline(...).drawArrays(...).
    • JG: that seems like something a user library could add easily
    • KN: yes. But it’s also free for us.
    • CW: there is marshaling back to JS that would happen every time.
    • JG: you’re issuing object references back to JS that are immediately unreferenced.
    • CW: seems most people are OK not having that.
  • CW: right now we use u32 everywhere in the IDL. Problems: not typical IDL; and buffer size as 32-bit uint it casts buffer sizes to 4 GB. While huge, not sufficient for everyone.
    • KN: we can use u64 for those entrypoints. Should be fine because if you take an int represented as a double (53 bits), if you have a 64-bit int in WebIDL it comes in as the proper integer value.
    • JG: what if you put in 2^54?
    • KN: you lose precision, so it rounds.
    • CW: that’s one area where I think we should introduce a device size typedef. Same as Vulkan device size which is 64 bit uint.
    • JG: aren’t those mostly used for documentation purposes?
    • CW: yes. Could have texel size, etc. typedefs which are just typedefs for ints. Helps with documentation.
    • JG: I sort of like them just being integers.
    • KN: from JS perspective, I think a size_t in WebIDL looks the same thing as a 64-bit int. Only changes what type you get in C++ in the implementation. Everything is “Number” in JS unless we add BigInts to the API.
    • JG: to clarify, the reason I like ints is that reading through the entrypoints I know what type of number they expect; no surprises.
    • KN: actually, there’s no size_t in WebIDL. So think it has to be 64-bit. (long long)
    • RC: this is the first API I’ve worked on where the size depends on the kind of computer you’re on.
    • JG: this is still true.
    • RC: do we really think people are going to make >2 GB things?
    • JG: yes they definitely will.
    • CW: we don’t want to paint ourselves into a corner with this.
    • RC: then if you’re on a 32-bit OS does JS let you make a 64-bit integer?
    • KN: JS only has doubles. No ints. (Except BigInts). Per WebIDL, if you feed in an int double value up to 2^53-1, it’ll come out as an int in C++ regardless of platform.
    • RC: I guess we should document that and tell people what the limitations are.
    • JG: it’ll work. If bindings code says “unsigned long long” in WebIDL, outputting that is as a 64-bit unsigned int at the C level.
    • RC: I’m OK with having the limit be highest value possible.
    • JG: The issue is that after 2^53, not all the integer values are representable. That’s OK because 2^53 will always OOM for us.
    • CW: who’s volunteering to make the IDL type-ful?
    • JG: I think we’re good.
    • CW: so no volunteers.
    • JG: what’s your proposal? I think things are good as is.
    • KN: think we wanted to put u64 on buffer creation.
    • CW: and various places taking buffer offsets.
    • CW: I can go through the IDL and change a couple of places.

Agenda for next meeting

  • CW: have a bunch we didn’t do today. #215. #198. (error handling)
    • Let’s assume #198 will be agreed upon offline.
  • CW: Binding model in WHLSL.
  • CW: Input vertex descriptor changes.
  • CW: PR burndown
Clone this wiki locally