Skip to content

Minutes 2019 03 18

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

GPU Web 2019-03-18

Chair: Dean (Corentin on vacation)

Scribe: Ken

Location: Google Meet

TL;DR

  • Vertex shader only? #240 (Pipeline without fragment shader)
    • Approved.
    • Need to put all of the rest of the “required”s into the IDL to express this.
  • Default values #241
    • Agreement that some default values are good.
    • MM: Want lots of defaults. KN/DM/JG: Want fewer defaults.
    • MM: I think ease of use is more important for users than preventing suboptimal performance.
    • Values:
      • Usage flags: Much discussion. Required for now.
      • Winding order (cw/ccw): Required for now.
      • Visibility flags: Required for now.
      • Primitive topology: Required for now.
      • Many others on the issue: Not discussed.
    • KN: Adding defaults is nonbreaking; removing defaults is breaking. Let’s try to merge the ones that are easy to agree on, and figure out the others later.
      • Agreement.
  • Bind group inheritance #171
    • 3 options presented in the issue. 2 more:
      • Vulkan style (complicated rules for when bindings are invalidated).
      • Never invalidate (encoding fails if bindings aren’t right at draw).
        • DM: Proposing this one.
  • Dynamic Offsets mod 256 #236
    • Approved.
  • Packed formats #224
    • Agreed to use the “straight” (not reversed) formats, pending investigation.
    • ai: DM: Implementing this on Vulkan sometimes requires e.g. mapping rgb565 to VK_FORMAT_B5G6R5_UNORM_PACK16. Investigate Vulkan formats to make sure all needed formats exist.
  • ES Module #243
    • Table this until we actually know what platform ES modules are going to look like.

Tentative agenda

Attendance

  • Apple
    • Dean Jackson
    • Justin Fan
    • Myles C. Maxfield
  • Google
    • Austin Eng
    • James Darpinian
    • Kai Ninomiya
    • Ken Russell
    • Shrek Shao
  • Microsoft
    • Jungkee Song
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert

Vertex shader only? #240

  • https://github.com/gpuweb/gpuweb/issues/240
  • Should we be able to run just the vertex shader, having a null fragment shader?
  • KN: everyone’s happy with this.
  • MM to write this resolution down in the issue.
  • MM: for every member of a dictionary in the API, should we mark it required or optional?
  • DJ: sounds like a good action item for Myles, putting question marks into the IDL.
  • JS: if we don’t put a “?” in the dictionary definitions, it’s by-default optional. Have to put [Required] in if it has to be.
  • MM: my AI: first pass segregate optional from required. Then we probably have to mark the required ones rather than the optional ones.
  • DJ: MM went through the dictionaries and found which ones have default values.
  • DJ: MM can you add something to the snapshot tracker saying that this has to be done?
    • MM: yes.

Default values #241

  • https://github.com/gpuweb/gpuweb/issues/241
  • MM: would be great if web developers didn’t have to specify values for everything.
  • MM: picked default values that Metal and D3D have. D3D has a 2-layered approach. “C” prefix means the values have defaults. Mostly agree but there are some differences.
  • KN: I don’t have comments beyond those I already left on the issues.
  • DJ: AI on MM to update and repost this PR.
  • MM: yes I have to update the PR. Default usage flags for resources? That one might be contentious.
  • JG: winding rule too.
  • KN: usage.
  • MM: for this particular field, chose the default to make the API as flexible as possible rather than as performant as it can be. Simple things should be easy, complex things possible. Rendering one simple thing, shouldn’t need to think about specific possibilities of all of their resources.
  • JG: I don’t like it because it gives devs the wrong idea.
  • KN: every time an app is creating a resource it’ll need to know these things anyway. If we require this field all the devs have to do is pick a few flags. It’s relatively straightforward. If you don’t have enough you’ll get an error later. Don’t think it’s necessary for this field to have a default because it’s not that hard to come up with the usages you need. Not really a convenience as much as a default if you don’t know what you’re doing.
  • MM: disagree that all developers should know what these fields should all be.
  • JG: but if they don’t do that it’ll be slow.
  • MM: for apps that are large and need all the perf they can get, they’ll fill these fields out correctly. The default values are for everyday programmers.
  • KN: I don’t agree. Nice to have default values for these things, because a lot of the time you don’t need to set them. If you want perf, have to. Lots of these defaults are nice to have, but this one you’ll worry about anyway.
  • DM: I like to think about it as functionality you opt-into. If you want to use texture as rendertarget, you need a renderpass, have to think about how to use the texture there, requires certain usage flag. Want users to opt into those usage flags.
    • Second concern: some combo of usages are not supported. If you request all usages for MSAA texture Vulkan will reject it. Do we specify some magic usage that’s reinterpreted? Don’t like that. You can not have UAV access to MSAA textures on some drivers, for example.
  • JG: are there any universal defaults? Default texture in my mind is sampleable and transfer-src-able.
  • DM: I think there are some defaults that generally work but don’t think we should fix on them.
  • DJ: seems most people are against MM’s suggestion there. MM what do you think?
  • MM: disagree but see the way the convo is going.
  • KN: would be good to get part of this patch merged and continue to discuss the others.
  • JG: could we go through and commit those that aren’t contentious?
  • DJ: we’ve gone through one of them.
  • KN: there’s “aspect” too, for example.
  • MM: winding rule: Metal has a default for it. If dev wants to draw triangles they aren’t going to do any culling. Shouldn’t have to pick a rule.
  • KN: would be nice if there were a special value like DONT_CARE. Only valid if backface culling is disabled.
  • JG: it also changes stencil application right? Think this is reasonable. Would be happy if it were CW, or required it. Metal is CW, everyone else is CCW.
  • MM: one of goals: this API can be used by beginners, and used where WebGL is today. Specifying this makes it harder for beginners.
  • JG: WebGL’s default is CCW.
  • DJ: in this case I think having a default is better.
  • KN: makes sense to me to have a default for this. Want to avoid depending on the winding order.
  • DM: you want this to be easy for beginners, but they’ll just pick a random value. How do they know?
  • MM: if there’s no default value and it’s required, it’s one more thing they have to write down.
  • KN: also something they can’t search for because it isn’t required.
  • MM: right. And their pipeline won’t compile, etc., because they didn’t type in the “clockwise” characters.
  • JG: it’s the way things work. Like if you don’t attach a vertex shader.
  • KN: winding order isn’t a big deal to get wrong. You don’t get a black screen most of the time.
  • MM: the beginners care about things other than winding order.
  • JG: I think it should be CCW.
  • DJ: I agree, we should take CCW as the default. Plenty of APIs that have optional parts.
  • DM: do you see how most users will use culling? It’ll be a required thing to know about. Catering to the span of people that are just learning and will run into problems with this default a few days later doesn’t seem like the right tradeoff to me.
  • JG: generally agree but don’t think it matters in this case.
  • KN: OpenGL has CCW, but also has backface culling on by default. Makes more sense to have a default if backface culling is on by default.
  • JG: depends if it’s more imp’t to put things on the screen, or goes fast.
  • MM: people will do their perf analysis.
  • JG: do you want the 75th % programmer to get it right quicker, or get it fast? AAA engines will throw engineers at it until it goes fast. They’re not using this API because it’s easy to use.
  • KN: beginners are going to use Three.js if they want graphics, TF.js if they want machine learning, and they’ll read some tutorials. Defaults don’t matter in the presence of a tutorial.
  • DJ: we’re not discussing ease-of-use of the API.
  • KN: adding defaults is a non-breaking change and removing them is a breaking change. We should default to having fewer defaults.
  • DJ: the default value means: 1) dev doesn’t have to write it in their dictionary; 2) impl sets it if not present. So not providing it should be an error; requires [Required]. Do we think it’s OK for dev to write this code, not put in a winding rule, and their app fails?
  • KN: yes. If the error reports what happened they’ll fix their one line. The bindings will fail because the field is absent.
  • JG: I think that’s preferable.
  • KN: I think it’s preferable for a lot of these.
  • DJ: is it preferable for this one?
  • JG: I think CCW is an obvious default, but that’s because I come from OpenGL and D3D.
  • DM: I think that if native APIs don’t agree on it then it’s not completely obvious.
  • MM: 100% of web APIs agree.
  • KR: are there right- vs. left-handed coordinate system differences? Because that changes the meaning of CW and CCW.
  • JG: OpenGL is left-handed.
  • KR: that’s not my understanding.
  • DM:
  • DM: when you choose a topology you’re not configuring functionality, like you do with e.g. depth bias.
  • KN: that’s another case where I think it would be easy for developer to pick one and go forward.

Bind group inheritance #171

  • https://github.com/gpuweb/gpuweb/issues/171
  • DM: we touched on this a few times. Each time was confusion. What if you change the pipeline? If your bind groups stay, which will be valid/invalid, which ones have to be rebound? Want clear model for the inheritance. Candidates are listed in the issue. There’s one more, the Vulkan bindgroup inheritance model, not listed, which is more complicated.
  • DM: if user rebinds and it keeps it then it ignores the call. Have to have a clear user-facing model.
  • DM: my proposal is: not have any invalidation at all. If the user makes a draw call, we see what pipeline is bound, what layout, and use the bindings that are currently present in the command buffer for this layout. Nothing gets invalidated.
  • KN: and if the binding is invalid for that layout it fails?
  • DM: yes.
  • KN: fine with me.
  • DM: it’s interesting. With Vulkan, you actually provide the pipeline layout. We’d be able to error earlier, at binding time.
  • KN: this is inside command buffer encoding? So we can’t throw an error until the end of recording?
  • JG: could throw errors in the console.
  • KN: possibly.
  • MM: so if developer binds some resources that don’t match the layout and then bind some that do, that’s OK?
  • DM / KN: yes.
  • KN: I think that’s easy to understand from developer point of view.
  • DM: I proposed this model because it matches the vertex shader binding model. It’s how it works in Vulkan and other APIs.
  • KR: will we have expensive per-draw-call validation?
  • DM: good question. We are currently doing eager binding: when user binds bindgroups, try to do it immediately. If mismatch, record that it doesn’t match. So at drawcall time only have to check if everything’s bound.
  • KN: it’s all in a command buffer so it’s ahead-of-time.
  • JG: doing work now in order to do less work later.
  • KN: I don’t think this is more expensive than the other models.
  • RC: the only other one I can think of is, you have a function call that takes everything that you need to validate. Not like OpenGL style, where you set a ton of state.
  • JG: I would love that - D3D-style “fat” descriptors.
  • DM: this doesn’t match what people are doing in practice. BindGroups are used to change state at different rates. If you had to bind everything at once it would be more expensive and differentiate itself from the native APIs.
  • RC: so if validation is done lazily we’re in the realm of dirty bits. And as KR pointed out, making draw call validation slower.
  • DM: I’m fine with changing this model as long as we do the same thing for the vertex buffer binding model.
  • MM: how expensive is this?
  • KN: it restricts the number of draw calls you can make.
  • MM: so then do DM’s eager binding suggestion.
  • JG: don’t think that changes much.
  • DM: it checks when you change the BindGroup, not when you draw.
  • JG: it’s still an extra thing to do at draw call time. What KN was talking about before.
  • JG: can we get a PR for this?
  • DM: I will write something up.
  • MM: when you write it up what will you write? It’s not exposed in the IDL.
  • DM: the explanation document somewhere.

Dynamic Offsets mod 256 #236

  • https://github.com/gpuweb/gpuweb/issues/236
  • DJ: looks like these have to be divisible by 256 because of NVIDIA hardware.
  • MM: there’s nothing to be discussed really because this would go in a spec which we don’t have yet.
  • DM: this is the same alignment we’ll use for buffer views?
  • KN: I think so. Same set of restrictions I think.

Packed formats #224

  • https://github.com/gpuweb/gpuweb/issues/224
  • DM: native APIs don’t think about packing the same way. An outsider is Vulkan because you read the packed formats in the opposite order. Suggest we define these packed formats in the same way as Metal and D3D12.
  • KN: I don’t have any other ideas.
  • MM: sounds great.
  • JG: concern: WebGL defines them in the Vulkan way.
  • MM: are there Vulkan systems that are big-endian?
  • JG: think so.
  • DJ: My suggestion: accept this straight format. Option is one or the other.
  • JG: does that mean that on Vulkan we’ll have to swap things?
  • DM: Vulkan will have to use internal formats in a different order. Don’t expect any actual work do be done.
  • RC: for all Vulkan formats, are there ones with the components in the opposite order?
  • DM: in Vulkan there are a lot of formats.
  • MM: Metal definitely doesn’t have the formats in the opposite order.
  • KN: Vulkan does.
  • DM: what’s the value of us saying that some formats are packed, and some not, if the ordering of channels is the same? Don’t think we have to say that something’s packed.
  • JG: alignment rules are the same…?
  • DM: Alignment is a concern if things are placed in memory, but we don’t do that.
  • JG: My only concern would be if this affects the texture upload path, for example. In OGL we run into issues uploading things as BGRA vs. RGBA and uploads take longer. Sounds like we’re safe from that?
  • KN: I suppose that when it compiles the pipeline it takes care of it.
  • MM: I thought Vulkan’s tenets were that it didn’t do that sort of thing.
  • DM: when you upload into a texture you upload into a buffer and then copy from that buffer. No reinterpretation when doing that copy. Vulkan doesn’t interpose there and neither should we.
  • MM: pending further investigation should we resolve?
  • JG: think we should just define the straight order of components.

ES Module #243

  • https://github.com/gpuweb/gpuweb/issues/243
  • DJ: should we write APIs as though we’re an ES module? Have to import webgpu into their namespace? Then could not expose things on window/navigator directly. Seems this is an issue that should be taken up by the TAG.
  • KN: sounds fine to me, is blocked on there actually being a way to do this. We should wait for this to be better spec’ed.
  • MM: should we resolve on an intent?
  • JG: when ES modules are published we should try to be an ES module.
  • DJ: would this have an impact on WebAssembly?
  • JG: we’ll find out.
  • KN: agree. Heard something about this but not sure how it works. Also prob depends on host bindings.

PR burndown

Agenda for next meeting

  • DJ: going through open issues saw that David has raised a few and he hasn’t been on the calls for a while. Should we resolve on Github or wait for him to join the next meeting?
    • MM: or if we put this on the agenda will he be able to join?
    • KR: encourage you to reach out to him.
    • DJ: ok, let’s do this in 2 weeks rather than 1 week then.
    • DJ: will go through some of those PRs. Most of them are either approved or have changes requested.
  • JG: how about PR burndown for the agenda next week?
    • DJ: good idea. People w/open pull requests that are approved, let’s try to clear them out.
    • KN: would like to clear out some of these during the week.
Clone this wiki locally