Skip to content

GPU Web 2023 09 07

Jump to bottom
Corentin Wallez edited this page Sep 7, 2023 · 2 revisions

GPU Web 2023-09-06/07 Pacific-time

Note that unless stated otherwise this is a GPU for the Web community group meeting and not a working group meeting.

Chair: KG

Scribe:

Location: Google Meet

Tentative agenda

Attendance

  • Apple
    • Mike Wyrzykowski
  • Google
    • Gregg Tavares
    • Kai Ninomiya
    • Ken Russell
    • Stephen White
  • Intel
    • Hao Li
    • Jiawei Shao
    • Zhaoming Jiang
  • Mozilla
    • Jim Blandy
    • Kelsey Gilbert
  • Mehmet Oguz Derin

CTS Update

  • KN: Ryan is back and working on AbstractFloat rounding tests
  • KG: have WebGPU CTS on CI on Linux/Mac, joining Windows. Optimistic about being to upgrade to ToT soon.

“Tacit Resolution” Queue

  • Empty!

WebGPU Compatibility Mode · Issue #4266

  • Gregg posted doc to internal-gpu@ - https://docs.google.com/document/d/1rT3vF2WnTJxKNx1ZIZBBKKtq1_32XJ_mcKMPRFb7NWQ/edit#heading=h.dvxpdk5zkp0
    • Should give some background on complexity of various emulation solutions
  • KG: more precise numbers of % of devices supporting various things?
  • GT: don't personally have that info, hope someone else does.
  • KG: looks like limits are ~½ of WebGPU limits.
  • GT: about that. These aren't even the spec limits - GLES 3.1 spec min limits are much, much lower. <1% of devices are below the limits listed in the above doc. For example, min 3D texture dimension is 256 in the spec - but no device supports less than 1024.
  • GT: possible solutions are pretty terse. More details follow in the doc.
  • KG: sketching - easy-to-emulate, we can treat as implementation notes and focus on more difficult ones?
  • GT: correct.
  • KG: did you include a strawman of what the API'd look like?
  • GT: right now, only 2. One is you pass in a "compat" flag, and things are validated out. Other than that, we just emulate everything and carve out some core functionality into features.
  • KG: one concern raised - is this forward-compatible.
  • GT: nothing changes here that isn't forward-compatible. Everything that works on ES 3.1 will work on full WebGPU. Question is how far back do we emulate, or just validate things out.
  • KG: think consensus hasn't gotten to that point. Reservation from Apple about whether the general concept of this is forward-compatible, whether we can get rid of this in the future.
  • GT: not aware of any examples that would prevent
  • MW: MM and I discussed it. In general if we're moving in the direction of things that are possible and not super performance impactful to emulate, then we're fairly fine with this direction. Just want to push more in the direction of not having so many restrictions with compat mode.
  • KG: float16 for renderability. Core spec also doesn't guarantee. In practice do most devices support it?
  • GT: not sure. According to gpuinfo it's 40% that support it. Not sure whether those devices really exist.
  • SW: original proposal issue has the suggested IDL. 3 changes. Compat mode in requestAdapterOptions, "isCompatibilityMode" in the adapter, and the third is the hint for the view dimension in textures.
  • SW: depending on how far we try to emulate texture views - if we say the hint's mandatory, it's mandatory. If we say it's optional,
  • GT: I'd say, no mandatory - fail validation if misuse.
  • SW: more, validation failure if you specify it and then use as different type.
  • SW: tried to dive into one issue, see how it'd look in "no compatibility mode, just unship it and make it an optional feature" and how it'd look in compat mode. https://github.com/SenorBlanco/webgpu-per-attachment-blend-state/blob/main/proposal.md
  • SW: largely the same in how they affect validation. More just how you enable this validation with the flag.
  • KG: This is helpful. Thank you.
  • KN: w.r.t. these feature removals - we can support them on some GLES devices. this one, + float16 renderable. So might want more feature names for those. TBD how they'd be requested in the core API as well.
  • KG: some desire to have fewer features. Great to understand float16 renderability better.
  • KN: ES 3.1's a pretty high bar. We're tracking most of them.
  • KG: also should ask ourselves how important these things are in core. (They're in core, so probably important.) Personally need more time to think about this. Docs you provided are super helpful.
  • GT: Apple mentioned in Github issue some possible solutions to depth shadow texture issues, sample mask issues. Time to detail these more? Would be helpful to know how much work/perf this emulation would cost.
  • MW: can do that.
  • GT: if you have one for the blend state one - we don't see one, since you can write to storage buffers in shaders, so it's impossible to emulate.
  • MW: discussed this. Require making copies of resources, run multiple passes - can detail it, but maybe we don't do this because it's too expensive.
  • GT: are we comfortable unshipping things we already shipped? Would tell devs you need to request higher limits, request non-optional things.
  • MW: have you considered making compat mode features enabled by default? Or too inconsistent w.r.t. how features work in WebGPU?
  • GT: personal opinion: part of the point of those things is that you know what you're enabling. If you ask for all of the limits you won't realize you won't run on 50% of the devices out there. WebGL gave you the max limits but extensions had to be enabled manually.
  • KR: data point about Unity - they'd like the compat flag rather than just emulating everything, would probably enable compat mode by default in WebGPU exports, and would warn devs about things like too-large assets. Aside from that, would be handled entirely in their engine and wouldn't affect devs' code.
  • GT: I'd also be happy to write a polyfill that adds the compat mode validation in order to be able to test on a browser that doesn't have it.
  • KN: Q to Apple: you're OK with compat mode flag as long as we push as far as reasonable toward emulating things. Would you intend to implement the compat mode flag & its validation even though you don't need it on your platforms?
  • MW: after we have our WebGPU impl, it's something we'd aim to do for conformance. Our primary concern and reason for emulation: otherwise we keep the set of baseline tech a bit too far in the past.
  • KG: sounds like lot of details to go through, but that there's some consensus toward compat-mode flag. Exciting. Let's hash out more details offline.
  • KG: thanks so much for all the work documenting this!

Investigation: Render to 3D texture · Issue #4251

  • HL: rendering to multiple slices of 3d texture is optional supported in native platforms. Not just for 3D textures; can be used to render to element of 2D array texture. Another WGSL extension. For rendering to slice of 3D texture: D3D can restrict to slice of subresource. Vulkan can't render to 3D texture directly, but can render to 2D texture array for 3D texture as of Vk 1.2. Metal, the subresource only be whole texture at mip level for 3d texture view, it provides a depthSlice property to specify a single slice to render to.
  • HL: selecting depth slice of 3D texture in render pass is best choice. This is also my proposal. Slice property in RenderPassDescriptor.
  • GT: can I attached 8 slices of the same texture?
  • HL: I think so.
  • KN: multiple slices of the same texture on the same render pass?
  • GT: yes.
  • KN: probably possible. Suspect that if you do this in Vulkan, the memory layout of the texture you're rendering into will be changed into a contiguous plane, then 2 different slices will be disjoint regions of memory.
  • KG: interesting option, finding 3D texture as output. In shader, specifying which layer to render into. When discussing outputting to multiple views. Binding different individual layers of the texture to different bind points, vs. binding a range of layers and having shader decide which one to render into.
  • KN: on slices - rendering to multiple slices wouldn't be allowed per our current validation rules. They aren't different sub-resources. Would need a carve-out in the spec.
  • KG: that was just expediency.
  • KN: would also need to make that restriction more specific to allow this case. 2D texture arrays are considered sub-resources.
  • KG: sounds like we just need a PR.
  • KN: what milestone is this, per definitions (1 or 2)? This is a core feature. Would be required by the spec, as written. Do we want to put that requirement into the spec now?
  • KG: choosing individual layers of a 3D texture to render into is in core WebGL 2 - so it's a regression in WebGPU. Should mean that unless it's really difficult, just put it into Milestone 1.
  • KN: works for me.
  • KG: don't think it's difficult. For binding multiple layers in the same view - not something you can do in WebGL 2. If it needs to be separable, Milestone 2 would be the right place for it.
  • KN: if optional feature, spec doesn't require it to be implemented.
  • KG: true.
  • KN: This is a useful question to answer. Do we consider optional features that we consider important for Milestone 1.
  • KG: probably not. Unless it's urgent and we want to ship it very soon, would put it in M2 core. If urgent, can talk about it for M1 as optional feature. If it's really easy that would also weigh in. How imp't to get this in now vs. next year (when M2 will happen). Otherwise, we're ready for a PR.
  • KN: clarifying - in WebGL2 you can render to a slice but not two at the same time. Want to add to core WebGPU without that feature unless it's trivial. (Might be.)
  • KG: if it's trivial we can put it in. Fixing the regression w.r.t. WebGL2 is Milestone 1. WebGL2, you can render to multiple slices at the same time, just need different binding points for it. One slice to framebuffer attachment 0, and one slice to #1.
  • HL: selecting multiple slices would be another optional WGSL feature. (Didn't catch this)
  • KG: HL are you interested in making the PR for this?
  • HL: I have a PR in webgpu for this proposal. https://github.com/gpuweb/gpuweb/pull/4254
  • KN: Q on that PR about validation.
  • KG: thanks, will review.

rgb10a2 vertex format · Issue #4275

  • KG: don't have them in WebGPU but they're in all the backends. KN thinks this is an oversight. Add to Milestone 1?
  • KN: was careful to make sure that the ordering is the same in all the backends.
  • KG: requires us to do a bit more work, but not bad.
  • KN: if you use vertex pulling but you need to do it for this format? Yes. A little work, but not much.
  • KG: let's leave it as M1 unless we decide it's difficult to implement. PR welcome.

Agenda for next meeting (2023-09-20)

  • Compat
  • Cleaning up PRs that show up. Hopefully we'll have reviewed the above incoming ones by then.
  • Please add more here!
  • Next meeting - probably ready to talk about Compat next week, but TPAC's next week, so should probably cancel.
  • MW: I'm not going to TPAC but MM is.
  • KN: CC might be there.
  • KG: let's defer a week, be sure to do our homework.
  • TPAC is next week, so no meeting 2023-09-13.
  • KN: on Compat, are we good to do work for the next two weeks?
  • KG: mostly homework for non-Google folks.
  • KN: don't want to be blocked.
  • KG: sounds like, consensus-wise, can move forward on validating out the ~4 parts that we think are very difficult. Think about polyfilling things on the medium difficulty list, though
  • KR: there are no medium-difficulty items on the list. 🙂 How do we decide?
  • SW: that one can be emulated by texture copies.
  • KG: the backpressure is to try to minimize the amount of emulated features.
  • GT: emulating cube map arrays isn't impossible but is a lot of work. If you're going to do it but then warn about it, why do we put the code in? Understand there are other considerations.
  • KG: concrete request, the ones we say easy to emulate, plan of action is to emulate them. Extremely difficult, eliminate from compat. Hard to emulate, can we go through those and sort them? These are more difficult than others? E.g. indirect draws via CPU readback? Thing we'll need to do in the meeting is make the judgment call for hard-to-emulate things.
  • GT: think that's true, but there's another basic issue. Are we unshipping things from core and put things into features? Or have compat-mode flag where things go down if you opt-in? Lower core limits to ES 3.1 limits?
  • KG: sounded like it's tolerable to have a Compat flag. One original pushback is if this is the real baseline, why isn't this WebGPU core? More of an extreme option. Other option of having a flag, and having WebGPU core be better than ES 3.1 - sounds like this has consensus. That's what I'm imagining will be the direction.
  • MW: we're OK with having the compat mode flag, just let's discuss what goes into it.
  • SW: that's great. The texture view thing, we don't have consensus on internally - it's challenging. Maybe make progress during next meeting, will try to gather more data.
Clone this wiki locally