10

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?

jeremyong
  • 267
  • 1
  • 11

1 Answers1

5

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 and OGL doc), 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, NV_fragment_shader_interlock, or INTEL_fragment_shader_ordering (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.
Nathan Reed
  • 25,002
  • 2
  • 68
  • 107
  • 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 Aug 09 '15 at 03:37
  • @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 Aug 09 '15 at 03:58
  • Gotcha thanks for the recommendation. Deferred decals is precisely what I'm implementing – jeremyong Aug 09 '15 at 05:30