<p>As far as I'm aware there's no way in either DX or GL to re-use RT 0's alpha for all the blending operations.  Unfortunately, it doesn't seem to be something that's supported by hardware.</p>

<p>You can configure different blend modes for each render target, or enable blending for some and disable for others; however, if blending is enabled for a render target, it always uses its own alpha.</p>

<p>There's also a mode called "dual-source blending" (see <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/bb205120.aspx#dual_source" rel="noreferrer">DX11 doc</a> and <a href="https://www.opengl.org/wiki/Blending#Dual_Source_Blending" rel="noreferrer">OGL doc</a>), which allows you to specify the alpha for blending with an entirely separate output from the pixel shader, not the render target's alpha channel.  However, this mode only works with one render target on current hardware.</p>

<p>So as far as I can tell, the only options for blending several render targets with the same alpha are:</p>

<ul>
<li>Output the same alpha on all render targets (sacrificing the ability to store other values to the alpha channel as you would in deferred shading, for instance).</li>
<li>Repeat the rendering in a separate pass for each render target, using dual-source blending.</li>
<li>Use UAVs / image load-store to execute the blending in the pixel shader (only works if geometry is non-self-overlapping in screen space, because there's no protection against race conditions; also probably kinda slow).</li>
<li>On hardware that supports it, <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/dn914601.aspx" rel="noreferrer">DX11.3/DX12 Rasterizer-Order Views</a>, <a href="https://www.opengl.org/registry/specs/NV/fragment_shader_interlock.txt" rel="noreferrer">NV_fragment_shader_interlock</a>, or <a href="https://www.opengl.org/registry/specs/INTEL/fragment_shader_ordering.txt" rel="noreferrer">INTEL_fragment_shader_ordering</a> (the latter also exposed by AMD GPUs).  These are three names for the same thing: basically a "critical section" in the pixel shader that lets you read-modify-write a texture atomically with respect to other pixel shader invocations. It essentially enables arbitrary programmable blending, but it's probably fairly slow, and only available on recent hardware.</li>
</ul>

CC BY-SA 3.0
2015-08-09T03:37:53.700Z
Yep, I think this was my conclusion too. Do you know offhand if this is the case with DX12 or (the unreleased) Vulkan? It has pretty large applications for deferred rendering as you've mentioned and none of the existing alternatives right now seem satisfactory.
jeremyong
CC BY-SA 3.0
2015-08-09T03:58:19.847Z
@jeremyong Sorry, I don't think there are any changes to blending operations in DX12. Not sure about Vulkan, but I'd be surprised; the blending hardware hasn't changed. FWIW, in games I've worked on we did a variant of bullet #3 for deferred decals, and preprocessed the geometry to separate it into non-overlapping groups.
Nathan Reed
CC BY-SA 3.0
2015-08-09T05:30:12.440Z
Gotcha thanks for the recommendation. Deferred decals is precisely what I'm implementing
jeremyong
CC BY-SA 3.0
2015-08-08T06:30:49.560Z
2015-08-08T06:30:49.560Z
Nathan Reed
<p>Say I have render targets 0 through N and RT 0 happens to have in its fourth component an alpha channel specified by a material or mask or something.</p>

<p>Is it possible to have the hardware compositor blend render targets 1 through N using the alpha of the first render target?</p>

<opengl><directx11>
Is it possible to alpha blend multiple render targets using a specified alpha?
jeremyong
# Is it possible to alpha blend multiple render targets using a specified alpha?

(Asked by: username_0 on 2015-08-07)

Say I have render targets 0 through N and RT 0 happens to have in its fourth component an alpha channel specified by a material or mask or something.

Is it possible to have the hardware compositor blend render targets 1 through N using the alpha of the first render target?

**Tags:** opengl, directx11


---

## 1 answers

### Answer by username_1 on 2015-08-08. Score: 5 | Accepted answer

As far as I'm aware there's no way in either DX or GL to re-use RT 0's alpha for all the blending operations. Unfortunately, it doesn't seem to be something that's supported by hardware.

You can configure different blend modes for each render target, or enable blending for some and disable for others; however, if blending is enabled for a render target, it always uses its own alpha.

There's also a mode called "dual-source blending" (see [DX11 doc](https://msdn.microsoft.com/en-us/library/windows/desktop/bb205120.aspx#dual_source) and [OGL doc](https://www.opengl.org/wiki/Blending#Dual_Source_Blending)), which allows you to specify the alpha for blending with an entirely separate output from the pixel shader, not the render target's alpha channel. However, this mode only works with one render target on current hardware.

So as far as I can tell, the only options for blending several render targets with the same alpha are:

* Output the same alpha on all render targets (sacrificing the ability to store other values to the alpha channel as you would in deferred shading, for instance).
* Repeat the rendering in a separate pass for each render target, using dual-source blending.
* Use UAVs / image load-store to execute the blending in the pixel shader (only works if geometry is non-self-overlapping in screen space, because there's no protection against race conditions; also probably kinda slow).
* On hardware that supports it, [DX11.3/DX12 Rasterizer-Order Views](https://msdn.microsoft.com/en-us/library/windows/desktop/dn914601.aspx), [NV\_fragment\_shader\_interlock](https://www.opengl.org/registry/specs/NV/fragment_shader_interlock.txt), or [INTEL\_fragment\_shader\_ordering](https://www.opengl.org/registry/specs/INTEL/fragment_shader_ordering.txt) (the latter also exposed by AMD GPUs). These are three names for the same thing: basically a "critical section" in the pixel shader that lets you read-modify-write a texture atomically with respect to other pixel shader invocations. It essentially enables arbitrary programmable blending, but it's probably fairly slow, and only available on recent hardware.

> **Comments:**
> **username_0**: Yep, I think this was my conclusion too. Do you know offhand if this is the case with DX12 or (the unreleased) Vulkan? It has pretty large applications for deferred rendering as you've mentioned and none of the existing alternatives right now seem satisfactory.  
> **username_1**: @username_0 Sorry, I don't think there are any changes to blending operations in DX12. Not sure about Vulkan, but I'd be surprised; the blending hardware hasn't changed. FWIW, in games I've worked on we did a variant of bullet #3 for deferred decals, and preprocessed the geometry to separate it into non-overlapping groups.  
> **username_0**: Gotcha thanks for the recommendation. Deferred decals is precisely what I'm implementing  

---

