Order-Independent Transparency Approximation with Pixel Synchronization
Submitted by Leigh Davies (Intel) on Thu, 07/18/2013 - 10:09
Transparency is a fundamental challenge in real-time rendering due to the difficulty of compositing in the right order an arbitrary number of transparent layers. The Order Independent Transparency sample using Intel® Iris™ Graphics extension for pixel synchronization shows a real-time solution using the extensions available on 4th Generation Intel® Core™, the algorithm was used by Codemasters in GRID2 to improve rendering of foliage and semi-transparent track side objects as shown in Figure 1.
Figure 1: The great outdoors in GRID 2 by Codemasters with OIT applied to the foliage and chain link fences.
This sample uses a new algorithm that builds on the work originally detailed in the following article on adaptive-transparencyby Marco Salvi, Jefferson Montgomery, and Aaron Lefohn. The article detailed how Adaptive Transparency can closely approximate the ground-truth results obtained from A-buffer compositing but is 5x to 40x faster, rather than storing all color and depth data in per-pixel lists and then sorting and compositing them (Figure 2) we re-factored the alpha-blending equation to avoid recursion and sorting and produce a “visibility function” (VF) (Figure 3).
The number of steps in the visibility function corresponds to the number of nodes used to store visibility information on a per-pixel level during the resolve stage, as pixels are added the algorithm calculates which previous pixels can be merged to create the smallest variation in the visibility function while maintaining the data set size. The final stage is to evaluates the visibility function vis() and composite fragments using the formula final_color= . 
The new algorithm makes 2 main changes over this approach; the first is the use of the Intel® Iris™ Graphics pixel synchronization extension. Pixel synchronization provides ordered Read/Modify/Write (RMW) for a given pixel. If two pixels in flight are being rendered to the same screen location at the point of the synchronization primitive in the pixel shader only one shader is allowed to continue and the one chosen is dependent on the order submitted to the front end. The remaining shader(s) resume once the first shader has completed in the order they were submitted. As shown in figure 4.
Figure 4: Pixel Shader Ordering
Using this we are able to merge pixels as they are rendered rather than in the resolve phase. Merging in the insertion phase removes the requirement to store the per-pixel list, meaning the algorithm now has a fixed memory size and removes any potential artifacts normally seen with A-Buffer and Adaptive Transparency algorithms when information is lost when the linked lists storage overflows. In addition, this also improves performance further by further reducing bandwidth requirements. The second major change was to the original algorithm used to merge the incoming pixels into the fixed set of nodes, rather than using the adaptive routine to create the visibility function we approximate the results by sorting and then merging the furthest pixels. This worked very well when similar color pixels are merged which is the case when rendering lots of foliage. Different insertion routines can easily be used based on the user’s requirements. The sample consists of a simple scene designed to showcase the difficulties in rendering complex geometry where transparency plays a major role in correctly rendering the materials, as shown in figure 5.
Figure 5: Intel OIT sample.
The user can select between alternatives transparency rendering techniques including;
- Alpha Blending (Figure 6), where solid geometry is rendered first followed by transparent objects sorted from the inner objects outwards.
- Alpha Blending with Alpha to Coverage (Figure 7) which requires MSAA and allows the use of depth buffering on simple transparent objects such as foliage.
- The original Adaptive Transparency routine detailed in the linked article implemented using DX11.
- The OIT algorithm using Intel® Iris™ Graphics pixel synchronization extension (Figure 8).
To run the final option you will requires hardware that supports the Intel® Iris™ Graphics pixel synchronization extension. The visual differences can be seen below
The sample makes no attempt to hide artifacts in the original alpha blending solution which in a real game could be partly solved by further subdividing the models and sorting relative to the camera, the intent is to simply show the types of artifacts OIT solves without the need to presort the semi-transparent geometry before submission to graphics API for rendering. There is a check box that allows the alpha blended foliage to read/write to the depth buffer showing the types of halo patterns that this would normally be caused if semi-transparent geometry updated the depth buffer. This debug option is included better show the amount of pixels passing the alpha discard test in the foliage shaders.
The sample performs the following steps when running the pixel synchronization OIT algorithm. First all solid geometry is rendered to the scene. Second we render any material that requires transparency; any transparent objects in this second stage updates both a ClearMaskUAV that can be viewed as a debug option and an AOIT surface containing multiple nodes of color and depth information per-pixel. Finally a full screen resolve pass merges the transparent pixels onto the back buffer where the ClearMaskUAV has been set. For debugging the sample allows you to view the depth buffer and to disable the OIT resolve to show the amount of geometry rendered using a standard forward rendering approach
The Intel approximated OIT algorithm offers different quality levels where the data is compressed into 2, 4 or 8 nodes. More nodes can more-accurately approximate the visibility function, but require additional memory and bandwidth. GRID2 used the 2 node version as the tradeoff between performance and visual quality was very favorable with only a minor visual difference and a noticeable performance gain.
The main code for the algorithm can be found in the pixel shader function WriteNewPixelToAoit in AOIT.hlsl and the AOITSPResolvePS function inAOIT_resolve.hlsl. The most expensive routine is generally WriteNewPixelToAoit in the insertion phase, by ensuring any pixel shader calling this routine uses [earlydepthstencil] testing to reject hidden pixels significant performance gains can be made. The more accurate and comprehensive the depth buffer at this point the more transparent geometry can be occluded leading to an optimization in GRID2 where even the trees were rendered to the depth buffer if the foliage was close to 100% opaque to reduce unnecessary overdraw.
One important point to note when running the sample is it starts with VSync enabled by default; this is done to conserve platform power and is strongly encouraged as the default behavior when writing PC graphics applications that are expected to run on portable PC’s.
Performance measurements should be taken with VSync off. When run without VSync the sample will display a range of statistics that are derived from DirectX timing queries on the GPU, these break down the time take into rendering the solid objects in the scene, rendering the transparent objects into the UAV surface and the final resolve pass, the statistics are disabled when VSync is enabled as they can’t be relied upon as an accurate reflection of the time taken to execute the algorithms. When VSync is enabled the system can reduce clock speed to conserve power especially on mobile platforms but a side effect of this is a very efficient algorithm can allow the system to clock down lower and distort the timing measurements.
| Attachment |
|---|