-
Notifications
You must be signed in to change notification settings - Fork 329
Compat mode: make f16 and f32 rendering optional. #4983
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Previews, as seen when this build job started (57f1c4f): |
proposals/compatibility-mode.md
Outdated
|
||
Without support, an error will occur at texture creation time as described in section 6.1.3. | ||
|
||
Support for both features is mandatory in core WebGPU. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SenorBlanco @kainino0x I have a question regarding how these optional features in compat / required in core will work.
Does that mean a core implementation must return these features as part of GPUAdapter.features?
Or should instead if requestAdapter returns a core adapter, the above features are implied and can not be requested?
I think we should prefer the latter as otherwise we will cause breaking changes to core when a website adopts compat mode, which does not seem to be the intent of compat.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer we make the features not possible to request in core, i.e., it is an error to request float16-renderable on a core GPUAdapter in its call to requestDevice.
Otherwise we introduce implementation breaking changes to core from compat and that would be unfortunate to set a precedent of having compat only features requested the same way as core.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Effectively a website which adopts 'feature-level-2' may find itself no longer longer on a UA which only supports 'core', but we should not have the scenario where a website which adopts 'compat' mode suddenly becomes less compatible across UAs
I think the features should be implicitly enabled on core devices and if you try to request them explicitly nothing should happen. I imagine this is how future feature levels would work as well. If we error instead this breaks forward feature-level compatibility. |
Sounds good to me. Do we need to change the wording for requiredFeatures in the core specification? Currently, requesting a feature which the UA is not aware of results in failure. Maybe distinguish between:
|
Thanks, Mike. It is a design principle that a Compatibility mode app must also be a valid Core mode app, i.e., it should run without error in a UA which only supports Core. It's my understanding that any new limits and features must also exist in Core, otherwise a Compatibility mode app that requests those limits or features would error in said UA. If the PR as written violates this, or doesn't make this clear, suggestions are more than welcome! |
this means |
I think we should make the features and limits which are only needed in compat mode only cause errors if not requested in compat mode. If we don't do that and we discover a feature is needed for compatibility post v1 of the core WebGPU specification, we now potentially break all UAs by adding a feature to compat mode until the UA supports the new feature. A website which adopts compat mode should not find itself less compatible on a UA which hasn't implemented compat, given core is moving to CR first independent of compat. |
I think it will be fine - just produce invalid textures - because we do |
This discussion about how compat features/limits should work is too complicated to figure out on this issue. I have filed #4987, let's please discuss there. (Hopefully there isn't some old issue about this topic that I'm missing - I think I have written on this topic before, but couldn't find where.) |
Introduce float16-renderable and float32-renderable as optional features in Compatibility mode, and required in Core.
They are optional feature now: gpuweb/gpuweb#4983 Yet compat feature level is unsettled. Remove to unblock requesting a GL context without extensions. Bug: 381214487, 382084196 Change-Id: I4c57defbebd4d9d68abe2b0b20eb6c50cafde953 Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/218700 Commit-Queue: Shrek Shao <shrekshao@google.com> Reviewed-by: Stephen White <senorblanco@chromium.org> Reviewed-by: Gregg Tavares <gman@chromium.org>
There seems to be a slight mismatch of multisample support.
multisample support of RGBA16F, R32F, Commenting here for potential discussion. |
^ Just to clarify for discussion, this issue doesn't affect the baseline requirements/capabilities of compat, it only affects what exact capabilities can be in these two new extensions |
When you say "compat gl" do you mean "compat on gl" or "compat-profile OpenGL"? |
GPU Web WG 2025-01-22 Atlantic-time
|
Introduce
float16-renderable
andfloat32-renderable
as optional features in Compatibility mode, and required in Core.Closes #4417.