Minutes 2022 01 12

GPU Web 2022-01-12

Chair: Corentin

Scribe: Loko / Ken

Location: Google Meet

Tentative agenda

• CTS updates
• Standardization timeline.
• Milestone triage (timebox 15m) #2073 (currently triaging V1 issues, start at #2073)
• Triage the issues without milestones (timebox 15m).
• GPUAdapter.name considered harmful #2191 (timebox 20m)
  • And discuss Brandon's proposal in Exposing GPU hardware information to web developers in WebGPU #2195
• (stretch) (again) Proposal: Add a usage bit to allow creating a view with different format when creating a texture #168
• Agenda for next meeting

Attendance

• Google
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • James Price
  • Kai Ninomiya
  • Ken Russell
  • Loko Kung
• Intel
  • Yunchao He
• Microsoft
  • Jesse Natalie
  • Rafael Cintron
• Mozilla
  • Dzmitry Malyshau
  • Kelsey Gilbert
• Brendan Duncan
• Mehmet Oguz Derin

CTS updates

• KN: New issue tracker using Github issues for CTS. Have migrated old temporary spreadsheet to new GitHub projects beta (which is great): https://github.com/orgs/gpuweb/projects/3
  • Provides a comprehensive list of the known testing that needs to be done.
  • Have a few more details to migrate, from Dawn’s issue tracker.
  • CW: Chromium side: features that we write in Chrome will come with additional CTS tests. That way people can focus on the CTS and not Chrome-specific tests.
  • KR: Are we ready to accept contributions from more folks? Do we have the guidelines for people to pick up tasks?
    • KN: I have more info to migrate to the tracker but it's not blocking people. People can take unassigned tasks and just start writing tests. Need time estimates, impl notes etc. - but most tests don't have anything like that. Ready for ppl to start using.
  • Docs are updated with info on using the issue tracker. Intro doc on contributing to CTS talks about how to update the issue tracker along with your changes.

Brendan Duncan's demo of Unity running in WebGPU

• BD: Got to a point where we can do real-world tests. Note, none of this is “released” and its all WIP with incomplete impls. No current estimate for when it will be released, but making good progress.
  • Demo is a sort of simple game example that comes with unity. Used as a test case to identify performance issues and compatibility. Built with both webgl and webgpu to compare performances.
  • Supports compute shaders already. Couldn’t do that in webgl which used the CPU instead.
  • Most rendering stuff is working. Unity builds pipelines dynamically based on the geometry. The demo is building the pipelines async now. You can see some artifacts because of this. (Trees disappear for a couple frames because of state changes).
  • Performance improved with the async though because before it would just drop frames entirely instead of some missing geometry/rendering artifacts.
  • Didn’t need to do much to make it work with webgpu.
  • Using Tint to do the shader translations at compile time.
  • HLSL -> GLSL -> SPIR-V, through Vulkan tools -> WGSL, through Tint
  • Probably compiled into HLSL again from there. :D
  • The fact that it works is quite a miracle :D
• Enjoying working with WebGPU as an API. Great so far.
• Some perf issues we're working through.
• Areas in the spec being worked on. Cascading Shadow Maps - depth buffer can't be sampled with regular samplers, only comparison samplers. Have to convert depth->float texture to use with shader using non-comparison sampler. Being addressed in this CG. Can get rid of that render pass once that's resolved here.
• Hopefully can get experimental Unity builds with WebGPU support soon. Probably after WebGPU V1. But will do internal testing with it.
• CW: Incredible that the demo runs!
• BD: in terms of render pipelines - things getting loaded dynamically, states changing - in this demo, playing through the game and doing all the actions turned out to be ~100 different render pipelines being created. This isn't a huge game. And the timing, seeing about couple dozen of those render pipelines take over 1000 ms to create. Many, 300-400 ms.
• DM: How is it running right now? Async pipelines helped alleviate, but webgl should still be able to do this? How does it fair against webgl impl?
• BD: webgl is currently faster. Not a great AB test subject because they are under 60 fps. About 5ms faster on webgpu for generating the frame. More testing with bigger gpu-bound issues to get better performance testing numbers. Compute shaders are still a huge win.
• DM: Can’t you do this with transform feedback with webgl2?
• BD: We could if it was done that way in Unity.
• CW: There’s still a lot of low-hanging fruits for webgpu. We are currently compiling the same shader source multiple times. Chromium is a WIP, but having this demo allows us to see what is working.
• DM: What is keeping this from working on Firefox?
• BD: Done some test on firefox, but not stable. Not sure what missing features are, but it just doesn’t work at the moment.
• CW: Could you share the builds? Or only demo?
• BD: It is fine to share the builds. Not fully public, but for helping both Firefox and Chrome to help with Unity makes sense and is in best interest for all parties.
• CW: So exciting that I had to check it out!!

Standardization timeline.

• CW: About 5 years that we started this group. (Feb 2017) We don’t have a released thing yet. We need to reach v1. We feel really close though. Last quarter we closed more than half of the issues that were tagged for v1. A lot of issues are just things we need to make decisions on, but no one cares.
• CW: stress - this group's at a point where we can set a timeline and say - we plan to have a V1 by a certain date. I suggest May. It sounds aggressive, but doable. Would be really good to have a target.
• CW: one implication - we'll have to say no to some features that will take time.
  • sRGB discussion - view formats list vs. just a boolean. Need to reach consensus fast, or maybe that shouldn't be in V1.
  • Descriptors, parent objects - not trivial change. Need consensus, or it needs to be out.
• CTS catching up to spec. Each feature we add adds latency to CTS to being ready for V1. Intel, Google, and I hope others will hammer on the CTS. It's still behind.
• Please, let's try to aggressively stop adding features and instead fix all the small issues.
• Fine to spec new features/issues but close current issues.
• Each time new proposal for feature: is it in? Out? If it's in, does it warrant moving V1 shipment by 2 weeks?
  • Exposing object descriptors - just that would move WebGPU release date by 2 weeks. Is it useful? Is the cost outweighed by the utility of the feature?
• We have a lot of things where we can make progress offline - but a lot of cosmetic issues. Many of them have been blocked for months. Maybe for cosmetic issues, let editors say, we came to this resolution. If you care, you can disagree - but you have to be available to discuss the issue in the CG. It's the editors' job to make the spec nice.
• KR: 100% agree. Let's close the long development arc. Empower the editors to polish the spec.
• DM: Agree generally and would like to ship as soon as possible. Makes more problems since we have to decide which ones.
• CW: WebGPU v1 is a target - but many features we're talking about aren't HW dependent, but browser impl dependent. It'll be a living spec adding things over time. Can I use WebGPU descriptors on objects? At some point it'll be universally available.
• It'll be extension soup in some regard, but also a living spec with queryable features.
• Synchronous mapping isn't a hardware support thing, but it can become de-facto available eventually.

Milestone triage (timebox 15m) #2073 (currently triaging V1 issues, start at #2073)

• 2119
  • KN: Might need to consider this because it can become substantial. Somoene should at least consider it from a design perspective.
  • CW: Could this be something that can be deferred to editors?
  • KN: Editors can come back to the group once they know.
  • Will be discussed Mon.
• 2124 allow importing VideoFrames *
  • CW: Kai is it in? Let’s assume this is about lifetime, and split the webcodec issue out.
  • KN: Lifetime is not landed either. Maybe this is one of the things that we put a time limit on it.
  • CW: Tentatively yes.
• 2131
  • Resolve by editors
• 2191 GPUAdapter.name discussion
  • Definitely in V1
• 2195 exposing blocking ops on workers
  • KN: you just made a point about this
  • Think it's fair.
  • I definitely would have put this in post-V1, but people are concretely asking for this. Don't think they can do what they need to without it. Don't know how true that is in practice.
  • GT: neither Safari nor FF have offscreencanvas support.
  • KN: these are ML compute applications. Pushing data in, want to read them back.
  • GT: and they only want to run in Chrome?
  • KN: no, they only want to run WebGPU in workers without a canvas.
  • DM: not sure about blocking operations on workers.
  • KG: I don't find the argument that compelling yet.
  • CW: let's say, it's not in V1, see how many people yell at us.
  • KN: think ppl will use canvas readbacks since that's what they've been doing.
  • KG: we'll find out.
  • KN: suggested on this issue that we have blocking operations always, not just on workers, because otherwise they'll just use canvas readbacks.
  • KG: what do they want out of a blocking API?
  • CW: mapSync.
  • KG: strict comparison to WebGL - we give you getBufferSubData, and DevTools warnings when you do it wrong.
  • KN: we could make it just mapSync. Think that's all that matters.
  • CW: you want to keep this in V1?
  • KG: we should have one more round of discussions.
• 2218
  • Myles saying performance.now has privacy fingerprinting notice - should have the same in WebGPU.
  • DM points out we already have this boilerplate text.
  • CW: just close the issue? Not sure. Pinged Myles yesterday.
  • KN: close, and ask Myles to reopen if needed?
• 2372
  • Adding fillBuffer / clearBuffer
  • CW: suggest post-V1
  • KN: don't think anyone here wants this to be in V1, but Myles did. Have to ask.
• 2373 Allowing copying from any Canvas where you can call toDataURL
  • CW: to allow copyExternalImageToTexture from any canvas - ImageBitmap, ImageBitmapRenderingContext
  • KN: don't think this is important for V1.
  • CW: could be editorial.
  • KG: think we should put this in from a spec standpoint.
  • CW: so, "yes", and editors figure out how to make it happen.
• 2388
  • CW: Myles will want to discuss for V1 for sure.
• 2464 clarify endPass and pass commands after pass has ended
  • Clarification. Editors will choose something.
  • KN: we'll deal with this one.

Triage the issues without milestones (timebox 15m).

GPUAdapter.name considered harmful #2191 (timebox 20m)

• And discuss Brandon's proposal in Exposing GPU hardware information to web developers in WebGPU #2195
• (Myles is not here, so skipped)

​​Supporting MSAA without rendering capability

• DM: Forbid them and add validation error. They are useless because there is no way to fill out. Can only copy from and to. You can’t render to it, so you can’t fill it out.
• CW: what formats does this happen on?
• DM: related to the PR I merged the other day that exposes additional flags to texture format caps. Can support MSAA but not rendering.
  • RGBA8_SNORM
  • RG_SNORM
• CW: these don't have resolve caps in the WebGPU spec. Did change assume resolution to this issue was "yes"?
• DM: they don't support resolve but can technically support multisampling.
• RG11_B10_… is the other one affected.
• CW: if we can't copy to them …
• KN: can you use them as storage textures? If can't do anything with them shouldn't allow them. Borderline inconsequential. Editors' responsibility. We already decided on it.
• CW: editors, do what you do. :)

(stretch) (again) Proposal: Add a usage bit to allow creating a view with different format when creating a texture #168

• (Myles is not here, so skipped)

Agenda for next meeting

• For offline resolution
  • Describe resource aliasing rules #2065
  • Make error scope objects have same shape as DOMExceptions? #1884
  • Should we constrain the location of user input-output stage variables WGSL #1962
• Carry over the agenda from today. GPUAdapter info discussion is difficult, could use the time.
• Texture view reinterpretation also a bit controversial.
  • sRGB <-> RGB compatibility. Is this worth discussing for V1?
  • KG: should probably have a story for that.
  • KN think it'd be OK if we didn't have this for V1.
  • CW: add a boolean? If later we want to do view format, add it later / add validation?
  • KN: that's basically what my PR does. View formats by default there aren't any, but you can specify sRGB. Was supposed to be easy.
  • CW: but we still want to discuss for V1? So this is on the agenda for next week.
• KN: think editors will have some issues to air. Go through the list and backlog. Inconsequential issues, need to get group approval.
• KR: If they are really inconsequential, why do we have to circle back to the group? It costs meeting time.
  • CW: let's try to just have editors come in and say, here are the list of issues, no discussion but if you have feedback you can follow up offline.
• KN; we can try that for at least one meeting.
  • CW: aim for 1 minute per issue.
• CW: next meeting will be APAC-timed. Intel might volunteer topics.