Pluralize requestAdapters() and add GPUAdapter.isSoftware #1660
Conversation
|
Very nice! |
|
Would be best to update |
Part 1: Fingerprinting(Most of this section is actually about #1314, but that's closed, so I'll post it here instead.) Using the GPU for fingerprinting is very real, and very common. https://jonatron.github.io/webgl-fingerprinting/ is quite insightful. The W3C Technical Architecture Group presented a finding about why unsanctioned tracking is harmful. The TAG has has a design principle regarding device enumeration. A primary way fingerprinting here can be limited is a two-pronged approach:
An API which returns all the devices fails item 1 above. It would also encourage applications to iterate through the entire list, interrogating each device, in order to pick the device it wants to run on. The problem here is that this calling pattern is exactly the same calling pattern a fingerprinter would use. We wouldn't be able to differentiate the good guys from the bad guys. Even if an implementation wanted to somehow inject an artificial limit into such a design (possibly by subclassing An API where the implementation returns multiple adapters at the same time loses priority information about which criterion the application cares most about, and which criteria it cares less about. Requiring a back-and-forth conversation, instead of giving away the keys to the castle with a single call, is a principle of good privacy design: websites should only get access to the information they need, and no more. Part 2: This proposalPart 2a: The futureThe text of this proposal seems to attempt to resolve the problems described above. However, the spirit of this proposal still violates the above principles. This proposal still returns a list of multiple adapters, but adds this text:
By returning a list of devices, this proposal still encourages web authors to iterate over the list. By adding a new This is a step in the wrong direction. Not only that, but this proposal specifically specifically mentions this wrong direction as its intended path forward:
As above, this proposal is encouraging authors to iterate, because the return type is a list, and interrogate each device, because that's how they can check if it's a software device or not. We are not convinced that a single line in the specification will be enough to educate authors that they are, in fact, operating under limits, and should try to restrict the devices they ask for. Also, as above, returning multiple adapters with a single call loses priority information - information that would be present in a back-and-forth conversation with the app. We are also worried that returning a list makes it easier for browsers to willfully violate the specification and return all adapters. If the requirement is simply a line of prose in the spec, browsers can choose to ignore it, without breaking compatibility with existing Javascript content. However, if the requirement is baked into the type of the returned object, that is a contract which cannot be broken without also breaking compatibility with existing content. If the dominant browser does indeed willfully violate the specification and return all devices, content will be written that performs the problematic access pattern described above. And, because of this, non-dominant browsers would be forced to match their behavior, in order to maintain compatibility of the web. Part 2b: The presentBeyond these future-looking fears, we have concerns about this proposal, even if it was never amended or violated. Philosophically, a list is the wrong data structure to return a hardware adapter and a software adapter. It would be too easy to write code like: which is incorrect if the machine only has a single software adapter. A natural improvement would be to split But even that isn't sufficient, because it doesn't make sense for the distinction between hardware/software to use a different mechanism for low-power/high-performance. These axes are (philosophically) independent - it would be reasonable to expose a high-power software implementation that uses the P-cores of the CPU instead of the E-cores. Keeping these mechanisms orthogonal means that, for every possible value of Part 3: Another proposalOn 4-12-2021 and confirmed again on 4-19-2021, the Community Group resolved to go in the direction of an |
@toji @kainino0x I don't quite understand these claims. Do you think you could explain them? Also, if you believe |
We can generally assume that the number of options that affect the returned adapter will grow over time. Some concrete examples are the potential for a One of the concerns, if the options are stated in terms of "allowing" the given behavior or merely affecting it's priority is that it gets pretty confusing fairly quickly about what takes precedence when. For example: If I allow software devices and I allow compute only devices, what floats to the top? Does software take priority or compute? Or a device that's both? We can definitely define it in an algorithm, but it's difficult to get an intuitive sense for the precedent simply from the dictionary args.
Following from the previous point, the phrasing of Kai's PR, which you linked, attempted to address this by having it be an enum stated in various negative terms ("last-resort", "never") but this goes against some of the API guidelines I've heard from the TAG in the past (which is that option defaults should be falsey), makes it difficult for developers who specifically want a software adapter to get what they're looking for, and still doesn't completely resolve the ambiguity of what's returned. The plural adapter approach was intended to resolve this by letting the developer set their own criteria for adapter selections rather than trying to find away to align our specced preferences with their intended ones. An alternate approach that we could take to resolving those concerns is reframing
|
I was under the impression the WebGPU CG was proceeding under the assumption that this set of developers was so small that we shouldn't be designing an API around them. If developers don't want to use a GPU, writing code that uses the WebGPU API seems counterintuitive. Edit: Oh, I think I see the distinction. The set of developers who primarily want a software adapter to the exclusion of all hardware adapters is the small set. However, requesting a software adapter after you've discovered that the hardware adapter cannot be used for your purposes for some reason is more reasonable.
This sounds fine to us.
I don't think this is a dealbreaker, but I want to be clear that the Mac and iOS ports of WebKit don't plan on implementing software adapters at all. So we would just return |
|
For what it's worth, the CSS Fonts spec has a similar conundrum when looking up a desired font from a family. The request can say something like The way the CSS Fonts spec solves this is that there is a priority order for properties within the request: First, you look for the font with the closest |
|
Closed in favor of #1734 after today's discussion. |
…ogether (gpuweb#1660) The `resolveTarget,usage` test has only tested an invalid case (COPY_SRC | COPY_DST). So this PR adds more cases to check if the resolveTarget usage is valid. Issue: gpuweb#1618
4 participants
A variant of #1314, Kai's original PR to pluralize
requestAdapters(). Also serves as an alternative to #1634, in that this PR adds anisSoftwareattribute toGPUAdapter. During editors discussion we felt that this approach would be more straightforward and useful than trying to provide developers with an increasingly complex combination of hints to try provoking the desired adapter configuration to be returned.This PR also explicitly states that only a single hardware and software adapter are allowed to be returned from any call to
requestAdapters()in order to avoid fingerprinting concerns for the time being, though there's an issue in the text to indicate that we should consider gating the ability to return more behind the permissions API or similar.Preview | Diff