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 09:45:12 -0700
Cc: public-gpu@w3.org
Message-id: <6BE8A72C-5092-46B1-9C4A-4CF57A174A09@apple.com>
To: Kevin Rogovin <kevinrogovin@invisionapp.com>


> On Aug 6, 2019, at 12:55 AM, Kevin Rogovin <kevinrogovin@invisionapp.com> 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.

Browsers should be able to use derived pipeline state objects under the hood. They don’t need to be exposed as API to the JavaScript developer.

> 
> 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.

Metal uses imageblocks to achieve similar goals, and we’ve seen them used to great effect. Unfortunately, they aren’t present on all mobile hardware, and no desktop hardware, so support for something like this would need to be an extension. Given the complexity of such a feature, it’s large integration surface area with the rest of the API, and the set of devices which support the feature, I’d recommend that we pursue this after we finish the Minimum Viable Product version of the API.

> 
> 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.

Metal supports this use case with Raster Order Groups. Similarly to above, this would be a good extension, but because of its complexity and integration with the rest of the API, I’d recommend we pursue this after the MVP.

> 
> 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 16:45:49 UTC

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