should this be moved to GPUAdapterInfo?

Good question. Added some more reviewers for thoughts.

It's symmetrical with forceFallbackAdapter / isFallbackAdapter where it is, but perhaps that's because those predate GPUAdapterInfo.

Either way is fine with me. Slight preference to GPUAdapter due to consistency with isFallbackAdapter

Should isFallbackAdapter be moved to GPUAdapterInfo? #4971

I feel like the reasons we added GPUAdapterInfo to device certainly exist for featureLevel. #4810 A library might want/need to know if they're in compat mode. The CTS has had to workaround the fact that this info is not on the device.

I strongly feel that items should only be in GPUAdapterInfo if they also apply to the device, because we expose device.adapterInfo. That's true of vendor/etc., and of isFallbackAdapter (so indeed it probably should be duplicated there), but not features/limits. Similarly it is not necessarily true of featureLevel, because whether the device is "compatibility mode" depends on what features/limits are enabled on it. This is another reason I don't really think we should expose something like adapter.isCompatibilityMode/adapter.featureLevel and should instead expose it via the features system. Example:

adapter = await navigator.gpu.requestAdapter({ featureLevel: "compatibility" });
device = await navigator.gpu.requestDevice({ /* forward all limits/features from the adapter */ });

device.adapterInfo.featureLevel will return "compatibility", but if the system supports core then that will be incorrect information about the device, which is not a compatibility device.

However this is an orthogonal concern to this PR, so this PR LGTM.

(https://github.com/gpuweb/gpuweb/pull/4898/files is where I concretely suggested a "webgpu-core" feature which, if available and requested, upgrades all features and limits to their core values.)

Anyway, I just remembered that if we end up including this, there is one naming concern I have that I forgot about: adapter.featureLevel sounds like it tells you the maximum feature level of the adapter, but I don't think that's what we want.

I believe what we want is to tell you whether your featureLevel request was obeyed or ignored - that is, whether requestDevice() with no args will give you compat or core. This is hard to convey in naming, but could be defaultDeviceFeatureLevel or something.

However it may not be necessary; in the PR above I said:

Applications that do need to check that compat is enforced (such as tests) should create a device and then check whether the "webgpu-core" feature is enabled on the device.

The question becomes whether applications ever need to know this before requesting a device.

I would find it odd to request property "foo" and get back property "defaultDeviceFoo". Why are we not requesting property "defaultDeviceFoo" in requestAdapter(), in that case?

Naming aside, hopefully if we do things correctly, most people won't need to know what the returned featureLevel is. They'll use individual Features to give them broader (ie., finer grained) reach above Compat, if they need it.

I see this as:

1. A failsafe against late-added Compat features which Core-only browsers don't know about, so people have to use this for feature detection. (Hopefully we spec them all, so this use case is minimal.)
2. Useful for metrics gathering, a la webgpureport.org.

In either case, testing against a Feature seems asymmetrical when other things in GPURequestAdapterOptions end up as GPUAdapter properties.

(Let me know if I've missed any use cases.)

I would find it odd to request property "foo" and get back property "defaultDeviceFoo". Why are we not requesting property "defaultDeviceFoo" in requestAdapter(), in that case?

That's essentially the reason I think they should have different names. One is the feature level you requested - the adapter you get must have at least that feature level, but it may also be upgraded. The other is the feature level that requestDevice will default to, i.e. the post-upgrade result.

It is somewhat similar to forceFallbackAdapter vs isFallbackAdapter which are also differently named.
powerPreference and xrCompatible are not surfaced on GPUAdapter.

1. A failsafe against late-added Compat features which Core-only browsers don't know about, so people have to use this for feature detection. (Hopefully we spec them all, so this use case is minimal.)

Do you mean apps would check adapter.featureLevel === "compatibility" before requesting "some-compat-feature-we-missed"? If that's the case they should more straightforwardly just check adapter.features.has("some-compat-feature-we-missed"). (They don't need to know whether the browser knows the feature, unless it's actually supported on the system.) If I'm misunderstanding, sorry and please correct me.

2. Useful for metrics gathering, a la webgpureport.org.

As long as there is some not-too-verbose way to get the answer, I don't think it really matters if metrics gathering code is slightly simpler. I still like adapter.features.has("webgpu-core").

Stephen and I talked about the naming concern. I think there are three things that adapter.featureLevel could mean, none of which are obvious, that the developer could potentially think it means:

• The exact value requested in requestAdapter. This wouldn't be very useful so devs are less likely to think this is it.
• The feature level of the default "compatibility" if the featureLevel requested in requestAdapter() was obeyed, and "core" if it was ignored. (This is what I think it should mean.)
• Whether the max capabilities of the adapter are above or below core. This would be the same as adapter.has('webgpu-core') assuming we add that. It would be very easy to think this is the meaning initially, but trying it out in a compat-supporting browser should disprove this quickly.

So given that, I still prefer a more specific name like deviceDefaultFeatureLevel but I am fine with featureLevel.

(This is of course all assuming we keep this attribute, which I think is unnecessary, but as I mentioned before that's orthogonal to this PR.

I strongly feel that items should only be in GPUAdapterInfo if they also apply to the device, because we expose device.adapterInfo. That's true of vendor/etc., and of isFallbackAdapter (so indeed it probably should be duplicated there), but not features/limits. Similarly it is not necessarily true of featureLevel, because whether the device is "compatibility mode" depends on what features/limits are enabled on it. This is another reason I don't really think we should expose something like adapter.isCompatibilityMode/adapter.featureLevel and should instead expose it via the features system. Example:

adapter = await navigator.gpu.requestAdapter({ featureLevel: "compatibility" });
device = await navigator.gpu.requestDevice({ /* forward all limits/features from the adapter */ });

device.adapterInfo.featureLevel will return "compatibility", but if the system supports core then that will be incorrect information about the device, which is not a compatibility device.

However this is an orthogonal concern to this PR, so this PR LGTM.