Minutes 2021 05 17

GPU Web 2021-05-17

Chair: Corentin

Scribe: Ken / Corentin / others

Location: Google Meet

Tentative agenda

• Pluralize requestAdapters() and add GPUAdapter.isSoftware #1660
• What binding numbers are used by an external texture binding? #1721
• What happens in configureSwapChain and on canvas resize? #1691
• WebGPU logo/mark? admin#14
• pushDebugGroup / popDebugGroup on Queue #1672
• Agenda for next meeting (reclaim for WGSL?)

Attendance

• Apple
  • Myles C. Maxfield
• Google
  • Austin Eng
  • Brandon Jones
  • Corentin Wallez
  • Kai Ninomiya
  • Ken Russell
  • Shrek Shao
• Microsoft
  • Rafael Cintron
• Mozilla
  • Dzmitry Malyshau
  • Jeff Gilbert
• Andrew Varga
• Francois Guthmann
• Mehmet Oguz Derin
• Rick Battagline
• Timo de Kort

Pluralize requestAdapters() and add GPUAdapter.isSoftware #1660

• MM: Proposal BJ made last is fine with us.
• BJ: To clarify, it would be ok for an implementation to return null on forceSoftware
• BJ: isSoftware bit - hopefully satisfies all parties. If we can identify this, it's pretty trivial for someone to ignore that adapter if they want. As jgilbert's pointed out, it takes you conscious work. Won't accidentally copy from StackOverflow snippet. Doesn't prevent UA from surfacing SW adapter, shouldn't break apps. Hope this covers everyone's needs.
• MM: if someone doesn't specify forceSoftware then impl's forbidden or allowed to return SW impl?
• BJ: it's allowed. Chrome wants its own internal criteria - we know this driver's bad, so we'll give you SW impl that's high enough quality to support your experiences. If you want to avoid it, have to check isSoftware bit and move along. Don't want people to easily opt-out from software adapters.
• MM: little worried about battery use. If we return SW adapter when app developer didn't have a notion of software rendering - think default path should be, unless they explicitly ask for software, don't return SW. Have you considered this?
• BJ: I considered it. From previous conversations, thought this was the better direction.
• DM: the powerPreference is a pref. Still the UA's decision. If UA thinks there's enough power to expose SW impl, it should do so.
• BJ: would be legit for UA to say, you're on laptop, no power adapter, 40% battery, so I won't return you a SW adapter. Difficult to be consistent from user's perspective.
• JG: potentially. Allocations in general - if you make it too easy, people will say they only want HW rendering. Won't be able to see the content.
• KN: we want to encourage people to fall back to WebGL if there's no HW WebGPU impl. If they're falling back to WebGL then they have written that logic. Extra logic to check whether adapter is SW or not is minimal. But for users that write no fallback, we'd really like them to be on SW, to have something on the screen than nothing at all.
• MM: that's fair.
• CW: proposal then - forceSoftware request option. Browser's allowed to return null. Intent on Chromium side is that it'd never return null. isSoftware bit on Adapter, too. If you care about perf and have a WebGL fallback, you can do so.
• BJ: yes, that's correct.
• CW: is there consensus?
• MM: also, requestAdapter doesn't get pluralized.
• BJ: yes, that's another thing, since there were so many concerns about pluralizing it. If we find a need for requestAdapters in the future we could always create that as a parallel function. Just saying, that wouldn't be part of first step.
• CW: what about xrCompatible and computeOnly? Just to plan for these. I request xrCompatible? This one for example if it doesn't have xrCompatible device, guaranteed to not return one? computeOnly, you might get one that can render?
• BJ: yes. Discussed this a lot. How to consistently get system to give you what you want? Were coming up with all crazy enums. forceSoftware is very clear in what it does. Projecting that forward, "forceComputeOnly" - with an alternate thing on the adapter isComputeOnly. Boolean logic combining these is unambiguous. forceSoftware + forceComputeOnly = a SW adapter only doing compute. Not perfectly expressive, but unambiguous. forceSW + forceXRCompatible = also unambiguous. Probably nonsensical. Spec'd unambiguously.
• CW: so we're fairly confident that we can extend this in the future with more options.
• MM: agree with most of what you said, but probably wouldn't want isComputeOnly. Just error if you tried to render. Same for XR, just wouldn't work.
• BJ: agree with that.
• KN: (agree too?)
• MM: weaker argument - think it applies to SW adapters. There'll be fast/slow devices. App shouldn't be checking whether it's slow or not, but whether it suits their purposes. If app needs specific extension they should check for it.
• KR: Experience with the Maps team is that they needed to know whether they were software or even some known bad GPUs so they could not use WebGL.
• JG: you made a good point that the Maps team had to know if it was a poor class of device. Echoes Firefox's disabling of failIfMajorPerformanceCaveat. They wanted to know if it was "slow". Could you just check the device string? They said yes, they could do that. If y
• KR: WebGPU tries to reduce identifiable information, we should have the single bit for simplicity.
• <missed stuff>
• JG:
• KN: WebGL hardware will almost always go faster than WebGPU software. Want to be able to see WebGPU's sw-only and use HW WebGL. Go back to original proposal? Ask browser what's the preference order? I think isSoftware is OK.
• JG: I think it's our least bad solution.
• BJ: what Myles said about extensions is definitely true. They should check for that all the time, not using isSoftware as a proxy for anything else.
• MM: worried they'd do that.
• KN: we could expose all the extensions on SW.
• JG: you could, though, and some UAs might not be able to do this.
• KR: could we please converge this discussion and just expose the boolean?
• MM: I want to confirm with my team first.
• …
• RC: but you agree on plural vs. singular?
• MM: yes, we agree on that, and allowSoftware -> forceSoftware.
• MM: the question is whether apps should be checking this isSoftware bit, or running their app to see if it performs acceptably.
• CW: right now GPUAdapter has a named property. We could put the word "software" in it, but should have as little identifiable info in it as possible. Also more brittle. Different UA string, too.
• BJ: don't think we'd fake a real GPU name instead of SW adapter name to fool apps. People will look at the name and try to infer things.
• JG: you can definitely tell difference between Intel & a CPU rasterizer. Just don't say "bad", "slow", etc.
• MM: thought the name string was the debug string set by the app, not by the browser. If there's a name string for the device we'd object to that.
• KN: it's different. Name string is a place to put info about what the adapter is.
• CW: could you look at privacy discussion in the explainer? It's discussed there.
• MM: sure.
• DM: the way Myles sees this working, they'd do triangle rendering test & then figure out to fall back to WebGL?
• MM: yes, they'd run a few frames of their app and if it doesn't work well they'd fall back.
• BJ: that's a lot of reinitialization.
• KR: this does not work - has been tried - for Google Earth, Meet, Maps, etc. Has been tried.
• CW: ok, let's move forward on the agreed-upon points.
• BJ: ok, I'll close this out and put up a PR with the agreed upon stuff, maybe isSoftware too, just as discussion point.

What binding numbers are used by an external texture binding? #1721

• KN: any reason we wouldn't be able to say - for all the slots that go with external textures, we'll put them somewhere that doesn't collide with user's binding points? It is the number.
• MM: we've all agreed that the total number of binding points will decrease.
• KN: yes, it's about assigning internal binding numbers that don't collide with user bindings.
• MM: think that'll work in Metal.
• DM: are the ones the user specifies limited, or unlimited? If unlimited, impl probably has to rebind anyway. If limited, would be nice to support impls that don't need to rebind.
• CW: ATM the binding numbers are unlimited.
• MM: really? Vertex attributes, varyings are.
• CW: are they limited in the locations you give?
• MM: I proposed making them arbitrary, having the browser always remap them, and was defeated.
• MM: I think it'll work in Metal.
• CW: think that might have been for vertex attributes.
• DM: can we put a mini-survey about how we limit locations / indices? If impls have to remap bindings it's clear. If they don't have to, then there's a value in not forcing them to remap.
• CW: we need an investigation / proposal. This issue: either impls have to remap right now, and then they can do that and hide the internal bindings; or the binding space's limited to the user, and so we can use portion inaccessible to the app. In both cases, user doesn't see the internal bindings.
• DM: that's not what I was thinking, but you're right. Have cohesive approach here, plus addition of multi-location data. e.g. array support for vertex attributes, things that'll take multiple slots - prob want this in the future - need to figure out whether additional bindings / locations are counted, hidden, etc. If future impls will count them incrementally, should do so here, not do anything new.
• MM: seems remapping has a small perf cost, and larger utility to programmers. Need to make sure it's possible.
• KN: think we thought about this, it's possible to remap.
• MM: I'm mainly concerned about whether it's possible.
• CW: we have impl experience; it's possible.
• DM: look at bigger picture. Will we have varyings in VS that take multiple locations? Arrays? etc.
• CW: external textures are opaque. Don't know how many bindings are in there.
• DM: from user standpoint it's the number of bindings in there.
• CW: user can't access the internal bindings.
• MM: if we're going to do these remappings - bind matrix as varying to slot 3, vec to slot 4 - impl might remap slot 4 to 8 and go on.
• CW: could be that. Different semantic - bind matrix on one side, multiple vecs on the other.
• KN: matrix might be defined as taking particular sequence of binding points. Attribs are different from bindings.
• MM: think we need an investigation.
• KN: don't quite understand - for other types of indices, why do they matter to this question?
• CW: consistency.
• CW: for our impl it's clear we can remap them. DM could you open an issue with what you want to see?
• DM: yes, I will.
• DM: it doesn't cost us much to remap but also doesn't give us much. Most users won't run into these collisions though. Neither choice has huge tradeoffs.
• CW: arbitrary numbers are pretty useful to developers. They can essentially hash the name and give an ID based on that. Lot of old OpenGL like engines that used fixed GL IDs for specific textures. Sun texture = texture 1064, for example. Benefits to having such hardcoded numbers. Can't conflict because they're all different.
• DM: OK. We aren't doing any remapping in our impl right now, I think.
• CW: let's work on the issue. Fairly hopeful we'll resolve this quickly. Worth doing.
• MM: what specifically needs to happen?
• CW: DM will open an issue with what we need to figure out - so we can weigh on what native APIs do, what happens when you use multiple resources, etc. Hopefully conclusion's clear. Discuss next week.
• MM: this issue will be blocked on new one?
• CW: yes.

What happens in configureSwapChain and on canvas resize? #1691

• CW: mostly socializing the solution to the group.
• KN: instead of having anything get implicitly destroyed when you change canvas's width/height - swap chain itself has inherent width/height that doesn't change. When you create swap chain, can specify width/height. If not specified, they default to canvas width/height. Any changes to canvas width/height only take effect if you create another swap chain. Changing it won't destroy swap chain or textures.
• KN: configureSwapChain can fail if dimensions are too large. In WebGL we can explicitly downsize from canvas to smaller drawing buffer size. If that happens, drawingBufferWidth/Height is updated. Very few people handle this correctly, but it can happen. More of a problem in WebGPU. If size changes underneath you things will likely break because attachment sizes won't match. So we just fail if you try to create swap chain that's too large. Can put limit on max 2D texture dimension. Very predictable.
• MM: what happens if you change canvas width/height and not swap chain?
• KN: if CSS sizes of canvas not specified - defaults to changing those. Just like with CSS sizes - size of swap chain will be scaled to fit size of canvas on screen.
• MM: so 2 scaling ops?
• KN: really just swap chain size to CSS size.
• MM: so width/height attribs don't affect rendering? Only default value for CSS?
• KN: they're the CSS default values, as well as the configureSwapChain defaults.
• BJ: can you always make the swap chain smaller than canvas size? What about bigger?
• KN: yes. Most of time, swap chain will be bigger than canvas in CSS pixels, because most displays are high-DPI and you want more pixels.
• MM: sounds good to me.
• JG: only thing I worry about - if you stay inside limits, should expect creation to succeed. Not necessarily true.
• KN: OK. Only thought about that this morning.
• JG: on Mac, for example, can't create max width/max height thing on some drivers.
• KN: think we'd do some sort of out-of-memory handling. Maybe not guarantee full max-width x max-height is supported.
• JG: for testing in WebGL, had to at least be able to make a maxWidth * 1, and maxHeight * 1.
• KN: our testing would be those, and ensure those values + 1 fail.
• MM: pretty common to have canvas with width/height attrib set, and use CSS to show it high-DPI. You do this, create WebGPU swap chain, then change attribs of canvas element. You're saying nothing happens?
• KN: yes, unless you update the swap chain.
• MM: because app has to respond?
• KN: yes, for example, has to reallocate depth buffer.
• BJ: even in WebGL, you have to rescale projection matrices, probably have to redo intermediate render targets, etc. Just making things more explicit. No real disadvantage to how WebGL does it.
• JG: in WebGL, note that if you want to do pixel accurate rendering the CSS width/height and devicePixelRatio doesn't work.
• Comments from MM and RC.
• KR: (not stated in meeting) device-pixel-content-box in ResizeObserver provides this detailed information.

WebGPU logo/mark? admin#14

• Some feedback that folks like the Helvetica version, and not the one using the W3C's font.
• Difficulties using the same font at different sizes.
• CW: is there a web font we can use, and then have a fragment shader that renders the WebGPU logo?
• BJ: can do this in pure CSS. :) But could do it in fragment shader too.
• CW: would be nice to have reference logo and then stamp it.
• BJ: if want reference version, probably don't want shader code for that. SVG maybe.

pushDebugGroup / popDebugGroup on Queue #1672

• MM: can we just have this in one place?
• JG: not really.
• BJ: already have two. Command buffer level, and programmable pass encoder (from CW).
• KN: can't just have one. If devs want to be able to push/pop debug groups on queue, they'd have to split command buffers just to do this; that's no good.
• CW: or worse, split the render pass.
• MM: so if they want it on the queue and they want to do it on the command buffer they have to create a 1-command buffer?
• KN: could maybe make it so cmdbufs don't have to be balanced, but validation gets weird.
• CW: also underlying APIs require these are balanced.
• DM: are you sure?
• CW: I'm sure that Vk requires it's balanced.
• DM: per-command-buffer, no.
• CW: OK, I'm not sure any more now.
• CW: maybe we don't need to add it now.
• MM: I'm not going to stop progress. If group thinks this is a good way to go, that's fine. If we can't do it in only one place that's fine.
• DM: is there a good impl story on the 3 APIs for queue-level?
• KN: if we don't pass these to driver, only affects debugging tool you attach to the browser. Might change text validation errors, but doing that inside the browser. Not relying on driver.
• DM: looks like supported on D3D & Vulkan.
• KN: know they (who?) have it on cmd bufs, Not sure on queues.
• CW: let's have this on queues. Could do Web IDL validation & then drop the data on the floor.
• KN: could bundle this with the same submit as the next command buffer. We'll probably want to do this in Vk & D3D.
• CW: it's all invisible to the page.

Agenda for next meeting (reclaim for WGSL?)

• CW: seems we have some topics for binding numbers and GpuAdapter.isSoftware
• DM: we can resolve the binding numbers offline.
• CW: if just isSoftware, suggest we reclaim for WGSL.
• KN: need to put up PR for swap chain; probably don't need to discuss here. Need to put up PR for specialization constants, need to discuss a little here. copyExternalImageToTexture too.
• CW: think we can do it in 2 weeks.
• CW: JG can you see tomorrow with WGSL group if we can use next week's meeting for WGSL?
• JG: yes.
• MM: won't be attending WGSL call tomorrow btw.
• JG: could you attend next week's API call?
• MM: yes, only out tmw.
• CW: shout-out to Kai's ComputeBoids demo running on both Chromium & Firefox with WGSL! Shown at WebGL/WebGPU Meetup last week.
• KN: only portability issue was trailing commas. :) and arraylength.