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

Re: Some Feature requests.

From: Dzmitry Malyshau <dmalyshau@mozilla.com>
Date: Tue, 6 Aug 2019 11:37:55 -0400
To: public-gpu@w3.org
Message-ID: <d50e6c14-fd5e-31ad-9510-3ce38f6fdbd1@mozilla.com>
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,


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 Tuesday, 6 August 2019 15:38:20 UTC

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