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

Some Feature requests.

From: Kevin Rogovin <kevinrogovin@invisionapp.com>
Date: Tue, 6 Aug 2019 10:55:54 +0300
Message-ID: <CALKNkvHPuAUMKgn1gjG9H2yGnjUrjYJ_dYJQZQCFE6M4+udkiA@mail.gmail.com>
To: public-gpu@w3.org

 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

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

Best Regards,
 -Kevin Rogovin
Received on Tuesday, 6 August 2019 09:08:27 UTC

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