W3C home > Mailing lists > Public > public-gpu@w3.org > August 2019

Re: Some Feature requests.

From: Myles C. Maxfield <mmaxfield@apple.com>
Date: Tue, 06 Aug 2019 19:33:57 -0700
Cc: public-gpu@w3.org
Message-id: <985F3A54-C02E-4E97-A1E6-4FB6E8563738@apple.com>
To: Doug Moen <doug@moens.org>

> On Aug 6, 2019, at 9:42 AM, Doug Moen <doug@moens.org> wrote:
> As the sole proprietor of a small open source project, my goals are different from Kevin's. I am most interested in portability, followed by ease of use.
> I would like to use portable, easy to use abstractions that encapsulate GPU design patterns where you must write different code for different platforms. In some cases, experts will implement a library on top of WebGPU that provides these abstractions, and in other cases, portable abstractions are built in to WebGPU.
> I do not think that "making fingerprinting harder" should be a goal for the WebGPU group. I think it is impossible to prevent fingerprinting by limiting the GPU features that are exposed by the WebGPU API.

We’ve heard this defeatist argument before and entirely disagree with it. All sources of fingerprinting are things we desire to eliminate from our browser. Just because one attack vector is possible today doesn’t mean it will be possible tomorrow. 

It comes down to our users' expectations and desires. Users don’t want to be fingerprinted. Our job is to make that come true. 

> I wouldn't be surprised if you could fingerprint a GPU simply by testing edge conditions in the output of transcendental functions in a shader, or by using some other technique that it is impossible for this group to protect against.

Luckily, the shader compiler is inside the browser, so if transcendental functions are the problem, we can fix them.

> If GPU fingerprinting is possible at all, somebody skilled at the art will find it, write a library, and sell it to people who want to fingerprint browsers. There's big money in this. How easy it is to write the code is irrelevant, once libraries exist on the open market.

We have a long history of shipping fixes and mitigations when this occurs.

> I think the only way to stop GPU fingerprinting is to ensure that there is no way for information obtained from WebGPU to leak into code that has the ability to transmit data to the internet. One approach might be some form of sandboxing. Another approach might be to add "taint checking" to the Javascript language (Perl has this feature).

Yep, this is one way to attack the problem.

> I think this group should consult somebody with deep browser security expertise to provide advice on what (if anything) the WebGPU group should do about fingerprinting. For example, the people who write the Tor browser would have the necessary expertise. I perceive the Tor browser as having the best anti-fingerprinting technology, so if there are changes to WebGPU  that Tor needs, then they are worth considering. Ideally there would be a w3c browser anti-fingerprinting team that this group could interact with.
> If you don't have to worry about fingerprinting, then you can provide APIs for querying GPU capabilities. Experts can use these GPU query APIs to build libraries of portable, easy to use abstractions on top of WebGPU that people like me can use to write portable, high level GPU code. My main concern is that the existence of GPU query APIs might increase the likelyhood that code I write doesn't have portable behaviour, but I will defer to GPU experts to assess this risk on a case by case basis.
> Doug Moen.
> On Tue, Aug 6, 2019, at 11:39 AM, Dzmitry Malyshau wrote:
>> Hi Kevin,
>> Thank you for writing down your (employer's) use cases!
>> Ideally, these would need to be filed as issues on 
>> https://github.com/gpuweb/gpuweb/issues .
>> 1. Needs an investigation to be done (see others  - 
>> https://github.com/gpuweb/gpuweb/labels/investigation). Roughly 
>> speaking, this is very useful and IIRC widely supported, we should have 
>> it in the API.
>> 2. User clip planes are the thing of the past, found in none of our 
>> target APIs (Vulkan, D3D12, Metal). Therefore, I don't think this 
>> feature should influence WebGPU spec.
>> 3. This appears to only be supported in Vulkan (of the 3 APIs we target) 
>> and provides only a minor benefit (unless you have numbers to show 
>> otherwise?). Perhaps, this would work as a small extension, but it 
>> doesn't seem necessary for MVP or V1 of the API.
>> 4 and 6. These are similar (in a sense that both are addressed by Vulkan 
>> sub-passes). Finding a good model of the API that would be portable is 
>> difficult. There needs to be a solid investigation followed by one or 
>> more proposals before we can have this.
>> 5. I don't think any of our target APIs support this, so this feature 
>> can't be influencing the WebGPU spec.
>> 7. Haven't looked into it. Needs an investigation done.
>> You are welcome to file issues and help us with investigations/proposals!
>> Note that in general we are trying to not have a lot of variation in the 
>> exposed device "geometry". These extra flags and capabilities make the 
>> application take different code paths on different platforms, which 
>> hurts the portability property of the API and makes fingerprinting easier.
>> Thank you,
>> Dzmitry
>> On 8/6/19 3:55 AM, Kevin Rogovin wrote:
>>> Hi,
>>>  I have a number of feature requests which are quite important for my 
>>> employer's use cases.
>>> First the easiest ones:
>>> 1. Dual source blending, i.e. add the blend modes: "src1-color", 
>>> "one-minus-src1-color", "src1-alpha", "one-minus-src1-alpha", 
>>> "src1-alpha-saturated". Each of these has a direct analogue in Vulkan, 
>>> Metal and Direct3D12.
>>> 2. Add Hw-clip-planes where a query states how many hardware 
>>> clip-planes are supported. It is OK if the return value is 0. In 
>>> particular, if the GPU does not support HW-clip planes from its API, 
>>> it should return 0. I have quite a few cases where knowing if HW-clip 
>>> planes are available can change my rendering strategy and improve GPU 
>>> efficiency significantly. Lastly, using discard to emulate HW-clip 
>>> planes can have large, negative performance impact and is something I 
>>> (and others) should avoid.
>>> 3. Derived pipeline state objects. Not all of the targeted API's have 
>>> this feature, but those that do, like Vulkan, it can help. The main 
>>> use case is again that if two PSO's are quite similar, then a driver 
>>> can upload only the parts are different and compute in advance what 
>>> those parts that are different.
>>> Now the tricky ones which require significant thought to properly do:
>>> 4. Render passes with local storage. This was something that was 
>>> non-trivial in Vulkan I admit but the potential usefulness is 
>>> significant. The basic idea is the ability to declare a value in the 
>>> frag-shader as intermediate to be read from the exact same pixel 
>>> location in a later rendering pass. The big use case is for tile based 
>>> renderers so that temporary data is never sent out to memory. This 
>>> gives a large performance and power-saving boost for deferred 
>>> rendering strategies.
>>> And lastly, features that not all GPU's can do, but are game changers:
>>> 5. To *optionally* support the blend modes of khr-blend-equations 
>>> advanced. I just want the API to have a query to ask if it is there 
>>> and as extensions rollout for Vulkan or ability to emulate with Metal 
>>> as found in iOS, to use this feature if the GPU supports it. On the 
>>> desktop two of the three major GPU providers have hardware support for 
>>> this feature. Of the mobile GPU's I think most have this in their GLES 
>>> implementations.
>>> 6. For tile based renderers, the ability to read the "last" value of 
>>> the framebuffer at the fragment, something akin to 
>>> GL_EXT_shader_framebuffer_fetch. Again, not to require this feature, 
>>> but the ability to query it. Most tiled based renderers can support 
>>> this on some level and on the desktop, two of the three can either do 
>>> or emulate this feature. For a variety of situations, this can be a 
>>> game changer to improve performance as well. On mobile, I know that 
>>> atleast 3 of the GPU lines out there support or can support this feature.
>>> 7. Another useful feature is an analogue of 
>>> GL_ARB_fragment_shader_interlock; again two of the three desktop GPU's 
>>> have HW support for this feature. For a variety of situations, this 
>>> can be a game changer to improve performance as well.
>>> I would like to participate in the discussions, not just drop the 
>>> above wish list. I.e. I want to help make any, or all, of the above 
>>> land in WebGPU.
>>> Best Regards,
>>>  -Kevin Rogovin
Received on Wednesday, 7 August 2019 02:34:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:26 UTC