Skip to content

Minutes 2019 07 15

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

GPU Web 2019-07-15

Chair: Corentin / Dean

Scribe: Ken

Location: Google Meet

TL;DR

  • Bind point renaming #351
    • Concerns that having an adapter layer between WHLSL and WebGPU isn’t a good developer story but reusing spaceN of HLSL isn’t good either.
    • Resolution that WHLSL should have its own WebGPU first attributes
  • Immutable samples
    • Required on old iOS (pre iPhone 6S) but we’re not targeting these.
    • D3D12 team didn’t see perf wins, just the simplicity to specify samplers in shaders
  • Snapshot / testing
    • Google will contribute the harness shortly, it integrates with WPT.
    • In the very short term, we can have test have both shading languages.
    • No appetite for taking snapshots of the spec that multiple browsers implement.
  • PR burndown

Tentative agenda

  • Bind point renaming
  • Immutable samplers
  • Threading/workers
  • Snapshot/testing
  • PR burndown
  • Agenda for next meeting

Attendance

  • Apple
    • Dean Jackson
    • Justin Fan
    • Myles C. Maxfield
  • Google
    • Austin Eng
    • Corentin Wallez
    • Idan Raiter
    • Kai Ninomiya
    • Ken Russell
    • Shrek Shao
  • Intel
    • Yunchao He
  • Microsoft
    • Chas Boyd
    • Damyan Pepper
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Mehmet Oguz Derin
  • Timo de Kort

Admin items

  • CW: Please register for F2F
    https://lists.w3.org/Archives/Member/internal-gpu/2019Jun/0011.html
  • CW: Spec editors: have not yet met with Dean to discuss how to decide this. Will do so in 12-14 hours.
  • KR: Was in contact with Khronos and they are suggesting an IP-free meeting at the New Orleans F2F on Tuesday afternoon. Email will follow; please keep this in mind.
  • DJ: Should ask for an update on the W3C liaison from Neil.

Bind point renaming #351

  • CW: happy for semantic of space declaration to deviate from that in D3D12. It’s just an attribute.
  • JG: no strong opinion, but think it should be solved within WHLSL.
  • DP: think this should be solved in WHLSL as well. Confusing to mix the two concepts together. Also, when you present the shading language for WebGPU, and you say “you have to translate this to this”, it’ll be confusing. The shading language should match the binding model.
  • JG: agree. We should get most shaders running already, just adding a 5-line prologue.
  • CW: so WHLSL should have its own “bindgroup=...” attribute, and no renaming done by the browser?
  • JG / DP: yes.
  • DP: my concerns are around the overall story for how we present WebGPU shading language. Where WebGPU talks about bindings and bind groups, I think the shading language should as well.
  • MM: makes a lot of sense. Our biggest concern is not the particular mechanism by which the 2 binding models are unified, but to have a good developer story. I suggested this proposal because it seemed best at the time, but if group thinks a different direction is better we can adjust it.
  • JG: my pref is for WHLSL to have a new bindings annotation (“bindings=N”) annotation like late-model GLSL does. When porting a shader, either doing it at API level or shader level, need to know what you want to do. People are trying to put this in the shading layer and that’s where I think it should go.
  • MM: that’s fine with us. OK with Google?
  • CW: renaming / no renaming, either way is fine. Having their own WebGPU attributes in WHLSL is fine too.
  • KN: given what DP said last week about how usual semantics for things like space= isn’t the same as bind groups, seems we should have things done by bindgroup and binding so that it matches WebGPU.
  • MM: ok, sounds like we’re in agreement. I’ll close this PR and we’ll modify the SL with grammar. Not sure what it’ll look like yet. There’s one last note about compat. It’s unimplementable to get 100% compat with HLSL on all platforms. It’s sort of a lie to say it’s source compatible. This is the first place where we’ll diverge in a significant way. How many of these paper cuts are worth it? The larger design question is, when there’s a language and it has all the divergences it needs to have, is that good enough? Fairly confident it will be, but something we need to keep in mind.
  • DP: qq on context. What’s view on supporting bindless in the future?
  • CW: hard to think about how that would work in WebGPU. Vulkan’s bindless model is complicated and hard to map to others. Also, array can be sparse array of bindless textures. Soon, need a bitset along with bindless heap to know which are present / absent, and branch on whether it’s there. It seems hard.
  • MM: our #1 concern is residency. Browser / OS has to be able to manage where resources live. Native APIs have external residency calls. We can do that, but next concern is, if you use a resource that’s not resident, have to modify shader source code, …
  • CW: that’s what I was thinking of. Bitset = residency of resources.
  • DP: ok, so it won’t be a week from now that someone introduces bindless. :)
  • MM: for first MVP we’re hoping to get something out the door where we don’t have to solve this problem, and later try to patch in bindless.
  • CW: WebGPU v1 can’t have bindless because Android doesn’t have it, but there will likely be an extension.
  • DP: reason I bring it up is, to have a design for the shading language that can eventually support it.
  • MM: good point, let’s discuss offline.

Immutable samplers

  • #356
  • CW: on iOS (old enough), can’t have shadow samplers unless they’re immutable. Need to have a way that you can bake the sampler.
  • KN: old iOS or old hardware?
  • CW: does Apple want to support WebGPU on GPU family 3v1? or 4 only?
  • DM: iPhone 6S is the first that supports this. Everything before needs immutable samplers.
  • DJ: in that case I only want to support iPhone 6S and above.
  • CW: then we don’t have a HW reason to support the feature.
  • DM: may have a perf reason. Did Damyan have any progress on that?
  • DP: not yet. Static samplers?
  • RC: didn’t come up in WebGPU’s context. We’ll find out.
  • CW: OK, let’s postpone. No HW incompatibility reason for this, only perf reason.
  • RC: does SPIR-V have this concept?
  • DM: Vulkan has this concept.
  • RC: is it a perf issue there?
  • CW: mostly used when you want to sample from YUV textures. I think.
  • RC: those have to be immutable?
  • CW: probably. Not 100% sure.
  • JG: sounds like we need more research.
  • DM: there is a quote from AMD in 2016 on this saying there is a perf difference because there are fewer memory loads with immutable samplers. Mainly theoretical.
  • CW: I don’t think we want to add features right now because they might be more performant unless we’re sure. Let’s see whether / if static samplers are needed for things in Vulkan, and DP / RC can get back to us from D3D team.

Threading/workers

  • DJ: Myles wanted to talk with Kai.
  • KN: started on it. Started writing spec text because in order to be able to do this, needed abstract concepts defined (adapter / device objects). Don’t have anything to share right now.

Snapshot/testing

  • CW: CTS is coming along. More work than we thought.
  • KN: we should just start writing tests. Don’t have any blocking tasks remaining. Should just put some tests in and start running it. It’s still in my experimental repo.
  • JG: would love to start trying it and contributing tests.
  • CW: last time we said it’d be separate repo in gpuweb org.
  • JG: is that what we want? It’s nice in WebGL that they’re in the same and that spec and test updates happen simultaneously.
  • KN: we should just do it. Can start working on it at any time.
  • MM: we’re starting to have a sizable repo too. Most of our tests have shaders. Do we have to delay writing a test suite until we have shaders?
  • JG: two directories?
  • CW: could have two shader sources in test, and use one or the other?
  • MM: if we do want to go that route would be nice to share the API code.
  • CW: in tests we’ve sometimes found it useful to generate shader sources at runtime. A bit harder to handle that.
  • JG: for WebGL tests we reuse the same shaders again and again. “Shader for textured quad”. Centralized location, not in the test’s source code. Also in WebGL the shader-centric tests are separate from most of the API tests.
  • MM: sounds like a pretty good design. If small set of shaders, we can just duplicate them, and have a lot of API tests that refer to them.
  • CW: tbh I don’t think we can get away with only a finite number of shaders in one directory, but hopefully we can get a good way.
  • CW: we’ll contribute the harness to whatever repo, and start cranking tests. Also, using old version of WebGPU typedefs.
  • MM: does it play well with web-platform-tests?
  • KN: it’s kind of complicated but yes, a lot of the work I’ve done is to get it working with wpt. Main issue is (1) have to setup so that you can run on machines that have GPUs, (2) per-test expectations for different hardware. Have a plan for how this will work but it’s non-trivial and half-implemented. Have a runner that runs inside wpt though.
  • CW: other half was about snapshot. We’re happy to take another snapshot whenever. Would be good to have all impls targeting one version of the API.
  • DM: we’re happy. One q: are your tests currently using GLSL?
  • KN: yes. It’s GLSL right now. Using version of shaderc I compiled a couple of months ago. Same one Babylon is using. It more or less works. A giant Base64 blob in a string. Will fix eventually.
  • DM: when you talk about multiple shaders, you mean WHLSL and GLSL?
  • KN: possibly.
  • MM: for tests trying to test the API I’m not sure it’s a big deal, but for shading language tests we probably don’t want to encode the quirks of your version of GLSLang into the API.
  • CW: on the Vulkan side there are also a lot of handwritten SPIR-V tests, too, to ensure drivers don’t over-specialize for glslang.
  • DM: I agree with Myles that if we have an official language (WHLSL) that we have tests written in another language.
  • KN: this is what we can do right now. We can update when we have the ability or need to.
  • DM: so we have an intention to update these shaders when WHLSL is ready?
  • CW: we have an intention to update them when we have a decision on the WebGPU shading language ingestion.
  • DM: the decision was about the language the API ingests, not about the language for the tests and documentation.
  • CW: I’d like to bundle that with the shading language discussion in August to not start debating this now.
  • MM: we can resolve that the tests designed to test the shading language should be written in the language that the browser ingests.
  • CW: what you said - just don’t put layers between what you’re testing, and yourself. Right now, unfortunately, we have 2 copies of the shaders in tests.
  • MM: sad, but don’t see another way until next month.
  • CW: back to snapshot. Rafael?
  • RC: I’m OK with doing snapshots, but we should have a deliberate plan of people going weeks / months against a particular snapshot. Then we as a group decide we want to change how things work in v1. That shouldn’t just be a bunch of PRs. A separate directory, etc. Single place to understand what v1 / v2 means.
  • JG: a branch sounds good.
  • RC: is ToT the future one? The one impls are working on one, and future work goes into a branch? I’m OK if there’s a single place where future work goes.
  • MM: are we discussing snapshots of the test suite or spec?
  • CW: the latter.
  • MM: seems sort of up to each implementation. On our side, we’d like to impl latest / best spec, but also compatible with bunch of web content. That’s our decision about what to implement when. It’s fine to make snapshots, but we’re going to implement what we think is best for product / web platform.
  • CW: once there’s a v1 there’s no such thing as targeting WebGPU - it will break going forward. If backwards incompatible change that goes into IDL, and we update the CTS, then all browsers that don’t implement that change can’t take CTS updates. Snapshot may just evolve in backwards-incompatible way for a while. Try to batch up breaking changes so that not all browsers have to target 3 different versions.
  • MM: just distinguishing between spec snapshot and impl strategy.
  • RC: I was talking about PRs on gpuweb/gpuweb repo.
  • JG: in WebGL because the conformance tests are in the repo we have snapshots of the conf tests. When we make incompatible changes with the tests we go back to a subset of the previous snapshots and try to make it so those tests don’t require the old behavior. This works well in a lot of cases. For larger changes it doesn’t work.
  • CW: concerns are that the snapshots we’re taking will be pre-v1, and can disappear as soon as no browser needs them.
  • JG: right. But it’s something we could discuss in PRs. Could agree to remove pre-v1 because we have pre-v2. Would prefer master is ToT, and than create snapshot branches / tags.
  • CW: branch is better because we can merge back and forth. Apart from process of dealing with snapshots, what do people think about taking a snapshot and calling it snapshot1 / mvp1 / etc.?
  • JG: sounds fine. As long as the snapshots aren’t mandatory for browsers to implement.
  • CW: this group has to decide to take it. Would be best if multiple impls implement it.
  • KN: not so useful if multiple browsers don’t implement it.
  • JG: from my standpoint the snapshot is the tests we’ve taken out of the tree. Think it’s too early to have formalized snapshot process. Idea is, taking advantage of conf tests. Can’t hold back to avoid breaking content. The only snapshot I care about is per-vendor that’s tested on CI.
  • CW: need snapshot to be able to write CTS and contribute to the same CTS.
  • JG: sounds like then when you want to take a new snapshot you’ll need a lot of PRs and I don’t like that. Ideally the CTS would match the ToT. If we can’t do that I think it’s too early to take snapshot.
  • CW: ideally CTS matches ToT of all browsers, no?
  • JG: no.
  • CW: then how do you contribute?
  • JG: browsers can pull down WebGL CTS into their own CI systems.
  • CW: sounds like lot of work.
  • JG: sounds like more work to develop against CTS snapshots.
  • KR: Think it is a good idea to have spec and CTS updated in concert and have CTS targeting ToT spec. Having a target for everyone to reach, is good so tests can be run and passing on at least one implementation before it is submitted.
  • KR: In WebGL bit the bullet one time and changed the CTS, a bunch of browsers started failing test but at least on was passing it.
  • DM: would like there to be some sort of snapshot not just for us but for users to target.
  • JG: I don’t think that’s realistic.
  • CW: recently we changed an enum. This is the sort of change where developers can’t really test it.
  • JG: but should impls accept both for a time? Need to pick a flag day.
  • CW: I was going to suggest some kind of flag week. Spec, CTS and browsers all get updated. Or, browsers don’t have to do things right away. Maybe once every 2 months?
  • KR: what about monkey-patching script that gets content running on older version of FF / Safari / Chrome?
  • KN: Think that’s an unnecessary amount of work for right now. For the next couple of weeks, devs won’t care if it works in multiple browsers. They’ll test on one and fix it if it breaks. When things are more stable, then it’ll converge and work on other browsers. Don’t think there’s a lot of value for customers to test on multiple browsers now.
  • MM: we’re all behind flags now. Another thing: like there to be not be two WebGPUs, like there are two WebGLs. Having to implement updates to the API while not breaking the old one is hard.
  • KN: that doesn’t happen until way in the future. Concerns there are different than here. Nobody intends to have snapshot 1 forever. That split is because of hardware. Not relevant now.
  • MM: I don’t want to have to maintain snapshots 1 and 2 concurrently.
  • KN: that’s the point of not releasing the API now.
  • CW: so no consensus? Keep spec and CTS ToT together, and people deal with it?
  • JG: think so.
  • MM: we’re all behind flags now. It’s up to each browser what parts they implement and bring up to ToT functionality now. As long as spec and CTS match that’s good.
  • CW: OK. I just have concerns that it’s hard to build an ecosystem before v1.
  • JG: it’s imp’t that we don’t build too much ecosystem before v1, because we explicitly don’t want to worry about backward incompatible changes.

PR Burndown

  • #355
    • DM: I don’t mind.
    • JG: right now GpuColor is floats, not doubles. It’s imp’t because it’s how we do binding generation. Has to support int32 and float isn’t big enough to hold those. Doubles are big enough to hold these.
    • MM: so up to how the color’s used, to know if number should be interpreted as floats 0..1 or ints?
    • KN: yes. If normalized format, use floats, otherwise ints.
    • MM: worth 2 color types?
    • JG: I don’t think so. DM proposed that.
    • KN: DM proposed Color type as a union of the two. Not technically possible.
    • DM: if it’s not possible I can’t object to that.
    • KN: could have intClearValue and floatClearValue. Double version handles this.
  • #357
    • Removes couple texture formats not implementable.
    • sRGB_R8 and R8 formats not supported everywhere on Vulkan.
    • R8_UNORM not supported on recent NVIDIA GPUs.
    • R5G6B5_UNORM, not supported on Metal on macOS.
    • JG: sad but willing to agree.
    • MM: OK.
  • #359
    • Renaming. Because desc is used to put shader module, and it’s only for programmable stages.
    • KN: this is a dictionary name, so not visible to the web platform.
    • RC: SGTM.
    • JG: weak yes.
    • MM: OK.
  • #370
    • Dictionaries taking optional values -> dictionaries are optional in parent dictionary.
    • JG: sure.
    • MM: OK.
    • RC: fine with it.

Agenda for next meeting

  • CW: more about immutable samplers. Will have more data.
    • DM: not sure.
  • CW: discard and discard-to-0 PRs.
  • MM: Kai do you think that we can do some research on multithreading?
    • KN: think so. Almost ready with the work I started on it.
  • MM: what about multi-queue?
    • JG: it’s on me. Investigation. Will target next meeting.
  • CW: PR burndown.
    • KN (added after meeting): Would like to prioritize load ops and clear values #284/#283/#268
  • CW: ideally, now talk less about features and more about spec text, errors, etc.
Clone this wiki locally