Multiplane overlay hardware requirements

Display drivers and hardware aren't required to support multiplane overlays. However, to provide multiplane overlay support, the hardware must meet the following requirements.

• Hardware must support nonoverlapping planes.
  • One plane can cover one portion of the screen while another plane can cover a different, mutually exclusive, portion of the screen.
  • If any portion of the screen isn't covered by a plane, the hardware must scan out black for that area. The hardware can assume that there's a virtual plane at the bottom-most z order that is filled with black.
  • Hardware must support overlapping planes:
  • The hardware must be able to enable or disable alpha blending on a per-plane basis. (Alpha blending is a technique where the color in a source bitmap is combined with the color in a destination bitmap to produce a new destination bitmap.)
  • Blending between the planes using pre-multiplied alpha must be supported.
• When only one output target is active, the active output must support multiplane overlays. In clone mode, where multiple outputs are simultaneously active, hardware shouldn't report that it supports multiplane overlays unless all active outputs support multiplane overlays.
• The Desktop Window Manager (DWM)'s swapchain (plane 0) must be able to interact with the other overlay planes.
• All planes must be able to be enabled and disabled, including plane 0 (the DWM's swapchain).
• All planes must support source and destination clipping, including plane 0 (the DWM's swapchain).
• At least one plane must support shrinking and stretching, independent from other planes that might be enabled.
• Planes that support scaling must support both bilinear filtering and filtering quality that is better than bilinear.
• At least one plane must support these YUV formats (for more info, see YUV format ranges in Windows 8.1):
  • Both ITU BT.601 and BT.709 YUV to RGB matrix conversion for YUV formats.
  • Both normal (or studio) range YUV luminance (16 - 235) and extended-range YUV luminance (0 - 255).
• Hardware must handle these register latching scenarios:
  • All per-plane attributes (buffer address, clipping, scaling, and so on) must atomically post during the vertical retrace period. When hardware updates a block of registers, these registers must all post atomically. For example, if the VSync occurs after writing 10 of 20 registers pertaining to the overlay plane, none of them will post until the next VSync because they can't all post on the current Vsync.
  • Each plane can be updated independently from the other planes. For example, assume the plane 0 registers were updated before the VSync and plane 1 registers are later updated when the VSync occurs. In this scenario, the plane 1 updates can wait until the next VSync, but the plane 0 updates should occur on time.
  • When multiple planes are updated during a single present call, the updates should occur atomically. For example, if a single present call is updating plane 0 and enabling plane 1, the plane 0 registers shouldn't post on the VSync unless the plane 1 registers also post on the same VSync.
• Transformation, scaling, and blending should occur in this order:

  1. The source allocation is clipped according to the specified source rectangle. The source rectangle is guaranteed to be bounded within the size of the source allocation.

  2. Apply a horizontal image flip, then a vertical image flip if requested.

  3. Apply scaling according to the destination rectangle, apply clipping according to the clip rectangle, and apply the appropriate filtering when scaling.

  4. Blend with allocations at other layers. Blending should be performed from top to bottom (or until an opaque layer is hit) in z-order. If alpha blending is requested, hardware must honor the per-pixel-alpha, and color value is pre-multiplied by alpha. The following pseudo code performs a source over destination operation repeatedly from top to bottom, (((Layer[0] over Layer[1]) over Layer[2]) over ¦ Layer[n]). Outside of the destination rectangle, each layer must be treated as transparent (0,0,0,0).

     Color = Color[0]; // Layer 0 is topmost.
     Alpha = Color[0].Alpha;
     for (i = 1; Alpha < 1 && i < LayersToBlend; i++)
     {
         Color += ((1 - Alpha) * Color[i]);
         Alpha += ((1 - Alpha) * Color[i].Alpha);
     }
     Output Color;
     

     Hardware can blend from bottom to top as long as the output result is the same. In this case, the following blend algorithm should be used:

     Color = Color[LayersToBlend-1];  // Bottom-most layer
     Alpha = Color[LayersToBlend-1].Alpha;
     if (LayersToBlend > 1)
     {
         for (i = LayersToBlend - 2; Alpha < 1 && i >= 0; i--)
         {
             Color = Color[i] + ((1 - Color[i].Alpha) * Color;
             Alpha = Color[i].Alpha + (1 - Color[i].Alpha) * Alpha;
         }
     }
     Output Color;
     

  5. Black color must be displayed at the area where not covered by any of destination rectangles from any layers. Hardware can assume that there's a conceptual virtual bottom-most black layer that is the size of the screen.