Chair: KG

Scribe:

Location: Google Meet

• Apple
  • Mike Wyrzykowski
• Google
  • Brandon Jones
  • Kai Ninomiya
  • Stephen White
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert
• Albin Bernhardsson
• Mehmet Oguz Derin
• Xiaoshen X

• Next meeting in the new year.
• WGSL is planning to meet next week so API could meet next week too if needed

• KN: Not a ton to report. A bunch of work went in to subgroup tests, and also GT has been doing more test work on textures.
• How to add features and limits for Compat after Core ships? #4987
• KN: I think we’re choosing between two and a half options
  • For limits, we expect that all of the limits we need for compat we need to figure out before we ship compat. Once compat ready, we’ll know what they all are. Important so that they can exist in safari on ship.
  • We might add features after compat ships.
  • We can add features but not limits, because limits would need validations.
  • We’re trying to figure out should we design something where we can add features to compat later, or exhaustively enumerate now, or try our best to enumerate now and then try to deal with adding things that might break in [already released browsers].
• MW: Do we expect all limits to be known before ship? (KN: Yes)
• MW
• JB: The interesting thing about compat is that it’s described as a list of missing features. So we’re in better shape than for [...].
• JB: It seems like we can enumerate now a list of features that are missing in compat [...]
• KN: The most difficult part is where we remove texture capabilities because they can be very fine-grained.
• MW: I guess if we don’t have too many additional features in compat, wouldn’t be a bad thing. If we keep adding support for things we need to split in compat but not in core, then we create this fragmented level of support. If we avoided that by adding so many small features, then this wouldn’t be much of a problem, because we identified most of the problems.
• KG: We need to add the things we need to add anyways. So we should do that, assume we've added all the things we can find. In the future will run into harsh realities where we have to add some things that don't quite work out, but suspect we are close enough that we will be OK, so don't need to overrotate too much on something that will be perfect in all eventualities.
• SW: Q from me. Do we want to accommodate the situation where there are older UAs that don't support these features and don't support compat. Provide a way to feature-detect these things in those browsers, e.g. "everything-from-compat-to-core" feature or adapter.featureLevel=="core", which guarantee.
  • E.g. we need to add a new feature between compat-and-core. Tell developers they should check for "some-compat-feature" OR "everything-from-compat-to-core" and that guarantees they have it.
• JB: In the event that we add some compat-to-core feature that we missed initially?
• SW: Yes. Especially because doing that now requires bikeshedding all the names and all the clustering right now.
• JB: But think that is the proposal. (...). Not worried about bikeshedding that much.
• SW: Fingerprinting…
• KN: right, we can cluster features to reduce fingerprinting regardless of how they're exposed.
• MW:
• KG: Proposal has way to check feature level?
• SW: Proposal not updated for feature levels, but that's how it works now.
• KG: Other thing: not just a problem of safari shipping. Also extended support releases like Firefox ESR. So sites will always have to account for older browsers.
• SW: …
• KG: Some point we're going to ship an ESR that has compat but with the older set of features. Browser can say "I don't know what this is" or "I know what this is and don't have it"
• KN: Good point. Did not think about this for .hasCompatibilityFeature …
• KG: setlike…
• KN: If we just put this in the regular features set, you can check wether it’s there or not. Don't think we need to distinguish "not known" vs "not supported"?
• KG: E.g. idea for shader-f16-arithmetic (without shader-f16). Someone wants f16-arithmetic but they're on an older browser that does support that but doesn't know the name. User has to check for shader-f16 or shader-f16-arithmetic.
• KN: Don't think apps need to do this at runtime. If they do the check right (has shader-f16 || has shader-f16-arithmetic) it will work. Features system designed with this in mind, such that apps don't need to know the difference.
• KG: Disagree… think it would make API more robust to issues like this, adding features (regardless of compat or core) [and having apps able to support both older and newer browsers].
• KN: Not dead-set on my position, just the logic that I used to design it.
• KG: In this discussion think we spent too much time figuring out what the current proposal is, we should have the proposal reflect the latest state so it's easier to discuss.

• SW: Explanation
• KG: Think we should just add the limit.
• KN: Agree, only caveat is we were able to avoid adding this limit for core because it was incorrectly reported by drivers, and actually was fine. Nice if that's true in GL too.
• SW: We get shader compilation errors from GL driver, unfortunately, so it's real
• KN: Does that validation come from the driver or from ANGLE? (Sorry should have asked this yesterday)
• SW: Need to check.

• KN: explanation
• KG: Think use-case for supporting older browsers is a minimal demographic. Since it is feature detectable, and not that many people will need to feature detect, we don't need to make it nicer.
• KN: SGTM.

• KN: attempting overview but this is gregg's issue
• KG: spec says it's implementation-defined. This is expected,
• JB: Agree
• AB: Two uses for timestamps that need to be considered. One is for adaptive performance, for dynamically scaling down resolution or LoD. Currently don't think we have anything for that, since we only have timestamps on per pass, not begin/end of frame. Second is for profiling. For that, it gets really complicated. Can go into some details about why it's complicated on ARM.
• KG: Think we have enough of an idea of ways it's complicated, so not necessary.
• KG: For total frame timings, thought you can enqueue an empty pass that just gives you timing.
• AB: Ah right.
• AB: To make timestamps make sense on ARM, only way to do it is with full pipeline barriers between every pass
• KN: Unfortunately no way to insert full pipeline barriers. But can use some workaround like wait for GPU idle, then submit only that work, and time it. Slow but gives results

• KN: summary
• KG: simplification of use but complication of validation. Think the extra work to simplify is not worth it. If someone comes to me with this problem, I'll tell them to just not bind that buffer.
• AB: Think this interacts with Compat because in GLES you have to have a vertex buffer bound anyway
• KG: Only true in compat profile GL … GLES doesn't require
• BJ: Only time we would run into this is when the attributes are generated by the application on the fly. But in that case likely something will get bound there anyway and won't notice. If handwritten then just delete it. (Or it's a real error!)
• KN: For webgpu.h we need a way to differentiate these two cases, but I found an alternative solution.
• KG: Since we have a solution for the issue, consensus sounds like leaving in current state.

• SW: summary
• KG: Can also do what WebGL does and just let people try and see if it works.
• SW: WebGL has the queries?
• KG: Believe so. But can effectively query by just trying. That's the ground truth for whether something works.
• SW: Counterpoint is if an application knows they need this, they need to do this up front to determine whether to fallback.
• KN: Would need to decide on the canonical way to check for support. Validation error? Internal error? Not a big deal, just need to decide on something.
• SW: Also have not gone through the texture capabilities thoroughly.
• KG: Sometimes the solution is just to try to create what you need, e.g. 1x1 texture with the format and sample count you need. You can rely on it working if your probe works the first time.

• KG: Polyfill?
• KN: Shouldn't even need polyfilling, all backends support it
• BJ: Except Vulkan has detailed limits for this.
• KN: IIUC Vulkan requires those limits to be at least 2*max texture size, and that would work on other backends, so can just make that the hard limit. (not introduce a new limit).
• KG: Ok! I think we’re just waiting on a PR to relax this [somewhat].
• BJ: Will likely pick it up
• AB: What about zero-area viewport? Requires Vulkan 1.1 or maintenance1.
• KN: We already require 1.1/maintenance1.
• BJ: Use case?
• AB: Unreal Engine uses it in multiview stuff for turning off a view, or something.

• KG: Next week? Or Jan 8?
  • KN: Don't think there will be anything other than compat. SW, projection for compat?
  • SW: Pretty sure we can handle everything online on PRs
  • KG: Next meeting Jan 8!

Agenda Jan 8 Jan 15 Jan 22

• Allow index < limits.maxBindGroups in getBindGroupLayout() #5042
• [landed, is there anything to discuss?] Compatibility Mode: update to use featureLevel. #5012
• Compat: float16(32)-renderable multisample support for RGBA16F, R32F, RG32F and RGBA32F: #4983 comment
• Compat: update new limits proposal. #5034
  • In particular maxXXXInYYStage auto-upgrades maxXXXPerShaderStage in both core and compat. (visa-versa is already true in core)
• [probably nothing more to discuss yet?] Compatibility mode: support devices without integer texture format multisampling #5004
• Compat: add "webgpu-core" feature so Compat adapters can be Core-capable #5036
• Compat: remove GPUAdapter.featureLevel #5037
• How to add features and limits for Compat after Core ships? #4987 (includes hasCompatibilityFeature()+requiredCompatibilityFeatures proposal)
• Add and name Features for all Compat Mode limitations. #5018