Advanced Blend Equations

[krogovin]

This is a feature request to add the blend equations as seen in GL_KHR_blend_equation_advanced (https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_blend_equation_advanced.txt).

These equations cannot be supported by all hardware. From the discussion on the mailing list at https://lists.w3.org/Archives/Public/public-gpu/2019Aug/0017.html, if extensions are realized as feature flags and written inline into the spec. If not, then ideally as an optional feature and the enums exist in the first spec.

[litherum]

Whatever we do here, we should make sure it’s implementable on top of Metal’s raster order groups.

[magcius]

A lot of hardware only supports KHR_blend_equation_advanced, which is effectively a wrapper around fragment shader interlock, before that was exposed. Quoting from the spec:

• KHR_blend_equation_advanced: Provides the new blending equations, but guarantees defined results only if each sample is touched no more than once in any single rendering pass. The command BlendBarrierKHR() is provided to indicate a boundary between passes.

I don't believe the non-coherent mode should be exposed.

[krogovin]

I think only going for KHR_blend_equation_advanced_coherent is best since emitting a BlendBarrierKHR() is nasty code-word for render cache flush really.

[kainino0x]

Vulkan extension support stats for reference. http://vulkan.gpuinfo.org/displayextension.php?name=VK_EXT_blend_operation_advanced

Does this functionality exist in D3D12 (I don't think it has advanced blend, but maybe an equivalent of Metal raster order groups?)

[krogovin]

I strongly advocate to make it optional or as an extension very quickly after 1.0 release. It is a game changer for some situations.

[RafaelCintron]

D3D12 does not have the equivalent of KHR_blend_equation_advanced.

[magcius]

It would be possible to emulate using Raster Order Views / Pixel Shader Interlock, but require a decent number of shader heroics and not perform that well. Given the drawbacks, I vote to exclude.

[krogovin]

Indeed. I'd be that is exactly what the NVIDIA driver does underneath too because NVIDIA does not give framebuffer fetch. Likely, knowing NVIDIA's way of doing diamond-like hardware, that image-load-store respects lossless color compression too. Or maybe they have truly something crazy going on between their ROP's and shader cores.

Let's make it an extension and leave it up to a browser implementation if they want to be heroic. I strongly advise that browsers should NOT be heroic and only report what a driver has ready out of the box and let apps or libraries do the nasty things.

[litherum]

Do authors actually want the specific blend equations this proposal advocates for? We’ve heard authors asking for programmable blending, not prepackaged equations like colordodge or colorburn.

[litherum]

[krogovin]

If I had to choose between nothing and blend-equations-advanced, I'd choose blend-equations-advanced. I am in the work of implementing UI's drawn by a GPU, and anything that lets me avoid copying from the framebuffer is a BIG, BIG, improvement help.

If the platform has frambuffer fetch, then it is tempting to go with that instead. However, there is a subtlety that is worth paying attention: framebuffer fetch almost forces a shader to be executed per-sample where as blend-equations-advanced has the blending per-sample, but the shader need not execute per-sample, thus rescuing MSAA's benefits.