GPU Web 2023 10 11

GPU Web 2023-10-11 Atlantic-time

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

Chair: Corentin

Scribe: Ken

Location: Google Meet

Tentative agenda

• Administrivia
• CTS Update
• “Tacit Resolution” Queue
• WebGPU Compatibility Mode (tentative consensus proposal) #4320
  • GPUTextureDescriptor.viewDimension defaults
• WebGPU Compatibility Mode (remaining issues) #4266
  • Disallow compressed texture copies (via validation) (restriction #2)
  • Disallow GPUTextureViewDimension "CubeArray" via validation (restriction #6)
• Proposal: read-write storage textures #3838
  • Discuss based on the new data Apple / Google
• Can buffer creation succeed on the device timeline after GPUDevice.destroy is called? #4294
• Proposal: formats-tier-1 extension #3837
• Separate read-only state for stencil and depth aspects. #3036
• depthWriteEnabled and depthCompare are required even for stencil-only formats #3905
• Support for arrays of textures #822
• Agenda for next meeting

Attendance

• Apple
  • Mike Wyrzykowski
• Google
  • Austin Eng
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Shannon Woods
  • Stephen White
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jim Blandy
  • Teodor Tanasoaia
• Nvidia
  • Anders Leino
• Mehmet Oguz Derin

Administrivia

• Corentin: Meeting about HDR
  • Put this off until November, will check with others
• Corentin: Socializing "stage" idea.

  • For our shipping processes, all the browser vendors have some means by which, before they expose a feature, they send an “intent to ship” notice. We’d like to start doing these “intent to ship” notices in Chromium, but they require signals from Firefox and WebKit on whether they’re positive or not about the feature. We have all these tiny features (unorm1010102), so doing those piecemeal would be a pain. Other specs like ECMAScript, they have a stage mechanism - Stage 3 indicates “positive signals from all vendors”. So far we’ve been assuming that “landing in the spec” indicates consensus, but it would be nice to formalize this a bit. A staging system might be helpful:

    • Stage 1: there’s a GitHub Issue
    • Stage 2: markdown PR has been written
    • Stage 3: PR has been landed

    No need to reach consensus today, but let’s shop the idea around and see what people think.

CTS Update

• GT: more compat things shoved in, shouldn’t affect non-compat

“Tacit Resolution” Queue

• Make GPUPipelineError constructor options optional #4292
  • KN: This should not be done. Removed from tacit resolution queue (will probably close).
• Require depthWriteEnabled and depthCompare only for formats with depth #4318
  • KN: This has landed already. Was it meant to be milestone 1 or 2? Is M1 okay?
  • KN: the issue it was attached to was M1, but in the meeting minutes it said ship in M2.
  • CW: think François was bothered by it.
  • KN: Jim, is it OK that this is already landed?
  • JB: yes, fine that this has already landed.
  • MW: fine with this too.

WebGPU Compatibility Mode (tentative consensus proposal) #4321

• PR above adds the Markdown doc agreed upon and requested last week. Doc says it's under active development, not to be implemented.
  • SW: as agreed upon last week.
• SW: urge you to comment if there are things you think we don't have consensus on.
• GPUTextureDescriptor.viewDimension defaults
  • What happens when you have 6 layers?
  • Proposal: 6 layers -> default to cube map. Will run more content without modification. But, different from the default for texture view construction. Consistency / simplicity tradeoffs.
• GT: Compat-only thing, thought want to be as easy as possible for developers. 6 layers almost always means a cubemap texture.
• CW: think we had it exactly this way at some point for the texture view viewDimension defaulting, and we changed it to what is now, and the reason is: if the app programmatically chooses a number of texture layers, and make a 2D array texture based on that data, all of a sudden there's an unexpected change in the behavior of your app when the data's in this specific form. Makes porting to WebGPU/Compat easier, but hides a footgun.
• TT: thinking about the same issue, but - may not be the same thing as with texture views. They'd default to cube here if 6 layers. But to create texture view, have to pass in the 2D array that you actually wanted for the atlas, for example.
• CW: view creation yes, but here, you also need to pass it as texture creation, otherwise your 2D array will sometimes be a cube map.
• TT: …made another point…
• KR: seems to me that we should have the special case for 6 since it'll make more content run unmodified. Loaders loading 2D arrays of variable length should just specify that they're creating a 2D array.
• CW: what about arrays of cube maps?
• GT: undecided as yet whether we'll have those as an optional unsupported feature in Compat.
• …more discussion…
• GT: not changing anything about createView, just createTexture. (Agreed, understood.)
• GT: I see Corentin's point about 6 layers being a cube map being "weird"
• CW: texture view creation viewDimension is optional. But if you want cube stuff, need to spec cube map or cube map array. If you want 2D array, that's a thing.
• KN: special case for createTexture would not affect default in createView. Create texture with 6 layers, then createView with no args will fail. Because Compat viewDimension for texture is cube, and in createView, it'll default to 2D array.
• SW: seems like a good reason to not do it.
• JB: I tend to agree. Seems people who are porting GL content are already writing the code.
• TT: same default for texture view creation maybe?
• MW: sort of feel the auto-conversion to cube with a dimension of 6 is odd. Side with Corentin on that.
• SW: OK, consensus.

WebGPU Compatibility Mode (remaining issues) #4266

• Disallow using compressed texture as a copy target (via validation) (restriction #2)
  • SW: copy/readback of compressed textures. Not possible in ES. One workaround - keep shadow copy. Double the VRAM usage.
  • SW: So suggesting to make that a validation error.
  • CW: note, would still be able to buffer -> texture copy to upload data.
  • TT: think this is fine.
  • MW: also fine with us.
  • CW: great, let's add that.
• Disallow GPUTextureViewDimension "CubeArray" via validation (restriction #6)
  • SW: Not present in GLES. Want to validate them out. Only other option is emulating them in the shader, but veered away from this solution in all the other Compat cases.
  • Compat-specific feature to reintroduce these if your hardware does support them.
  • CW: helps RW storage texture discussion later too. MTLGPUFamilyApple3 could support Compat. Right now this hardware doesn't support it due to not having cube map arrays.
  • MW: (thumbs up)
  • TT: sounds good.
  • CW: great, consensus.
• TT: Coarse/fine-grained derivatives
  • Point 9 in the Compat proposal. Two ways. Validate coarse/fine-grained versions, or allow them and translate to normal versions. Since no guarantees about the behavior of coarse or fine as currently written, think it's fine to just translate them to the normal versions.
  • KN: think we don't guarantee fine is fine, but think we guarantee that coarse is coarse. But can't do that in GLES.
  • KR: I checked the WGSL spec, it says coarse may produce fewer results than fine, so it should be fine (pun intended) to translate them to normal derivatives.
  • MW: thumbs up.
  • CW: consensus - translate to just normal derivatives.
  • SW: since nothing to do, maybe don't put in the Compat doc?
  • CW: agree, but let's record the decisions somewhere. (See below)
  • KN: looking at SPIR-V spec, "fine" derivatives must be fine. D3D spec seems to say "fine" must be fine and "coarse" must be coarse. Metal spec's handwavy but think it says the same.
    • https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#OpDPdxFine
  • KN: there's nothing in the GLES spec saying one way or the other.
  • KR: pretty sure GLES derivatives are always fine.
  • KN: think our decision is OK here. Think it's possible for GLES to give us a coarse derivative, or basically, to not support fine derivatives. And think WGSL requires support for fine.
  • KR: maybe just run the CTS?
  • KN: not sure we have sufficient derivative tests.
  • TT: revisit this later?
  • KN: will file a CTS issue.
  • KR: request: can we please put the discussion about coarse/fine in the Compat doc somewhere?
  • Consensus: yes, let's add an Issues section to the Proposals template, and put it there for the Compat proposal
  • KN(afterward): Filed https://github.com/gpuweb/gpuweb/issues/4325

Proposal: read-write storage textures #3838

• Discuss based on the new data Apple / Google
• CW: some AMD GPUs that don't have this, but a very tiny fraction. Mike reported that Apple3 GPUs don't have the cap, but we could drop them to Compat. Everyone OK adding RW storage textures with the restricted formats to core?
• MW / TT: thumbs up.
• CW: suggest we put this in proposals/ folder. Would like one UA to implement and validate this before putting it in the spec. Large-ish core feature. And this way we can train ourselves around putting things in the proposals folder.
• CW: TT would you be OK putting this into proposals/?
• TT: sure. Guidelines?
• CW: yes. There's guidelines in the README in the folder.
• TT: also merging tiers 2 and 3 into 1?
• CW: we agreed on a Tier 0 in core. What do people think of having a RW storage texture tier 1 extension, which combines tiers 2 and 3 in the current github issue?
  • TT: we're fine with this
  • TT: more context: tier 2 was only needed because we support Adreno 500. IF we merge 2 and 3, Adreno 500 series won't get the extension.
  • CW: seems fine.
  • TT: that's something you mentioned previously.
  • CW: feature level's optional for D3D, do we know its prevalence? Is it in FL 11_3? You only picked the formats required in 11_3?
  • TT: it says if any one is supported, all are supported. Next section - only for those you'd need to query each individually.
  • CW: group OK with proposal doc for these? Double-check the set of formats etc.?
  • TT: separate proposal?
  • CW: yes.
  • No objections.
  • CW: OK, let's go with these two proposals and decide separately when to land these in the spec.

Proposal: formats-tier-1 extension #3837

• CW: thanks for gathering data.
• CW: folks on Chromium side didn't look at this yet. Come back to this next week?
• TT: that's fine. Nothing to discuss honestly.

Separate read-only state for stencil and depth aspects. #3036

• CW: tried to do homework but didn't have time to finish it. Come back to this next week? MW noted on the issue that this is supported by Metal. Supported by D3D12, should be supported by Vulkan, is supported by GLES too in local testing.
• CW: TT suggested look at proposal from Dzmitry from long ago, where this might be supported in Vk without KHR_maintenance_2 if we rely on the general layout.

depthWriteEnabled and depthCompare are required even for stencil-only formats #3905

• Landed already, skipping.

Support for arrays of textures #822

• CW: Ken showed a WebGL example (sprites) demonstrating the need for this.
• JB: worth us talking about this in isolation, or more useful in combination with arrays of buffers, samplers, general binding array feature?
• CW: think it's useful along with the others. Uniformity restrictions might depend on the binding type. Think this issue will be long-winded, have back-and-forth with WGSL. Mostly a WGSL feature. Some API support.
• TT: should we investigate this for the other resource types too, as long as we're doing it?
• CW: yes. Guess someone can take homework to look at this. I might take a look. Just looking at docs, not necessarily prototyping things for the API side.
• JB: Naga already implements something like this as an extension. Can put a summary in the issue of Naga's syntax and how it's validated.
• TT: I might look into backend support, but probably not by next call.
• CW: how about - put on agenda for next call, and if no investigation, will drop it. Let's TT and me sync offline so we don't duplicate work.

Can buffer creation succeed on the device timeline after GPUDevice.destroy is called? #4294

• JB: looking at GPUDevice.destroy algorithm, we don't mark the device invalid until we "lose" the device. But we wait for the queue to drain first. If you call device.destroy() you can still do things like create buffers on it. Want to call device.destroy(), all ops then fail on that device noisily or silently afterward.
• JB: we're implementing this right now in wgpu-core. Would be nice if we didn't have to implement this almost-certainly-undesirable behavior.
• KN: as soon as you call device.destroy() you don't have to support any additional ops. That's the intent. The spec has problems. Everything you do does nothing and returns no errors. Except for mapping, we don't fake the mapping. We reject the promise.
• JB: leave this to editors?
• KN: think so. Spec may be correct - whether buffer was created or not should be unobservable.
• JB: except whether you ever see an error.
• KN: and if device is lost, you shouldn't.
• KR: good idea to add a non-normative note?
• KN: yes.
• JB: past that, happy to leave to the editors.

Agenda for next meeting

• WebGPU/Compat
  • Couple/few more items
• CW will try to come back for read-only separate depth/stencil (general layout in Vulkan)
• Support for arrays of textures, if we have an investigation
• CW: agenda seems light, what about canceling next week?
• KR: would kind of like to keep the Compat pipeline moving forward.
• SW: would also like to make continued progress.
• CW: OK, more Compat-focused then. And let's plan to meet. Let's try to have a bunch of Compat items so we can use the time efficiently.