Add synchronous GPUAdapter.info

[kainino0x]

Adds a [SameObject] readonly attribute GPUAdapterInfo info; to GPUAdapter.

Important points:

• The available info about a given GPUAdapter may no longer change. You can only get new info by getting a new GPUAdapter. (The only reason this should happen is if someone adds a permission prompt for fingerprintability.)
• requestAdapterInfo() is explicitly "deprecated (but not planned for removal)" (non-normative note)
• requestAdapterInfo() should never in the future change to add a user permission prompt (even with a new argument)
  • Technically it's possible if it's the first attempt you make to read any adapter info, but it would be fragile (accessing adapter.info before calling adapter.requestAdapterInfo({ pleasePrompt: true }) would cause the latter to not produce any new info). Instead, any permission elevation would need to occur before the call to requestAdapter(), for example through some new call that grants a new Permissions API permission.

Less important points:

• adapter.info returns the same JS object every time you access it.
• requestAdapterInfo still returns a new one each time for minor backward-compatibility reasons, but now always returns an already-resolved promise (a non-normative note promises this).

Fixes #4536

[github-actions]

Previews, as seen when this build job started (5fee248):
WebGPU _{webgpu.idl | Explainer | Correspondence Reference}
WGSL _{grammar.js | wgsl.lalr.txt}

[toji]

We definitely want to bring this up with the rest of the group, but if we do allow synchronous adapter info then I agree this is the way to expose it.

That said, if we change it to be synchronous I'd prefer to see requestAdapterInfo() deprecated and eventually removed. I know at this point it likely has a lot of callers, so we'd need to give it a really long lead time, but it's possible. Especially if Mozilla and Apple were to never ship with the request variant.

[beaufortfrancois]

@jimblandy What's your take on this PR?

[toji]

If the info available to the page changes for some reason (generally shouldn't), the attributes on the GPUAdapterInfo object start returning different values (like an empty string gets changed to a non-empty string).

Is there a scenario where this may happen that wouldn't also end up surfacing a new GPUAdapter? Given that we've backed away from permissions dialogs here and we've previously indicated that we don't want adapters to be long-lived objects, I suspect that anything that would change the adapter info is probably drastic enough that we can consider the old adapter expired.

[kainino0x]

Is there a scenario where this may happen that wouldn't also end up surfacing a new GPUAdapter? Given that we've backed away from permissions dialogs here and we've previously indicated that we don't want adapters to be long-lived objects, I suspect that anything that would change the adapter info is probably drastic enough that we can consider the old adapter expired.

We could do that. I was thinking of a case where for whatever reason we decide to expose more information about the adapter after you've already looked at it once. But that's probably never going to happen and if it did we could totally just expire the adapter. Good catch, I think it makes more sense.

[kainino0x]

Finally updated.

[toji]

LGTM (% group approval) with one nit.

[jimblandy]

Mozilla doesn't have plans to prompt the user when content calls requestAdapterInfo. We consider the bucketing of adapters into 32 or fewer distinct info values to be adequate fingerprinting control. So we don't need this info to be available only through asynchronous interfaces. Taking that opportunity to improve developer experience with a synchronous accessor seems fine.

[kainino0x]

At the meeting we particularly need to discuss whether we're deprecating requestAdapterInfo with the intent to try to remove it (firefox/safari could even ship without it), or just leaving it for compatibility.

[kainino0x]

Closing in favor of a new PR to avoid being too confusing by editing this one.

[Kangz]

GPU Web WG 2024-05-22 Atlantic-time

• KN: We more or less agreed to do this, the PR is up. There are a few points people should be aware of:
  • With this change, we’re saying that the available info about an adapter may not change: once you’ve accessed it once, it will keep returning the same thing. The only reason it would change if there were a permission prompt. Now the only way to get that new info would be to get a new adapter.
  • The old adapterRequestInfo should not open a user permission prompt, because it would create strange corner cases, depending on what you’d asked for first
  • This PR markes adapterRequestInfo as deprecated but not marked for removal. We should decide if we want to remove it. FF and Safari could just ship without it, Chrome could remove it all
• JB: no opinion about deprecation; seems pretty easy. Just immediately resolve the Promise.
• KR: agree.
• MW: not much of an opinion - our impl already resolves the Promise synchronously
• BJ: mainly a question - do we need a getter and the function version which fetches the same info. I'd argue "no". Given we have 2 major impls yet to ship, seems like good opportunity - if we won't use permission prompt for function version, phase it out now. FF / Safari ship without that variant.
• JB: seems removal impacts Chrome more than anyone else.
• CW: we're willing to do it, keep the wart for a bit, communicate with developers, then remove it. We don't expect a lot of usage of this API.
• KN: should I remove it?
• CW: yes, let's just remove it from the spec and we deal with it on the Chrome side.
• KN: OK. Spec won’t serve as a reference for it anymore, but think MDN's a good enough reference for this.