GlRenderPipeline.bind() derives a single, pipeline-wide blend enable and applies it to every color target. VulkanRenderPipeline bakes an independent blendEnable into each attachment. When one target has a blend function and another has Optional.empty(), the two backends diverge:
Pipeline | OpenGL | Vulkan |
|---|---|---|
target 0 has a blend function, target 1 has | blending enabled on both, function from target 0 | blending on 0, off on 1 |
The writeMask == -1 (null target) path also leaks the previous pipeline's colorMask/enable, but the frontend maps a null target to a detached FBO attachment (colorIds[i] = 0), so that leak is unobservable and is not the defect here.
Possible fix: Store a per-target boolean at construction and drive the enable from it instead of the global flag:
Comments 3
Half of this (different functions) is unsupported by OpenGL without GL_ARB_draw_buffers_blend (core-since 4.0), which is unsupported by RenderPearl. Only the first example is a bug (blend enabled for one target, disabled for another) as that is supported by GL 3.3.
Can confirm.