3- Thirdly Raster Ordered View is about the order of rasterizations of objects using special interlocks placed in 2nd gen Maxwell shader units just like in ROPs so it is also hardware accelerated. It gives the developer control over the order that elements are rasterized in a scene, so that elements are drawn in the correct order in the first place all at once (previously it was drawn first and then sorted afterwards in an order for correct image - too slow). This feature specifically applies to Unordered Access Views (UAVs) being generated by pixel shaders, which by their very definition are initially unordered. ROVs offers an alternative to UAV's unordered nature, which would result in elements being rasterized simply in the order they were finished. For most rendering tasks unordered rasterization is fine (deeper elements would be occluded anyhow), but for a certain category of tasks having the ability to efficiently control the access order to a UAV is important to correctly render a scene quickly.
The textbook use case for ROVs is Order Independent Transparency, which allows for elements to be rendered in any order and still blended together correctly in the final result (in a fast fashion due to ROVs). Order Independent Transparency is not new – Direct3D 11 gave the API enough flexibility to accomplish this task – however these earlier OIT implementations would be very slow due to sorting, restricting their usefulness outside of CAD/CAM. The ROV implementation however could accomplish the same task much more quickly by getting the order correct from the start, as opposed to having to sort results after the fact. So now Order Independent Transparency is finally fast enough to use it in real time rendering in games.
Along these lines, since OIT is just a specialized case of a pixel blending operation, ROVs will also be usable for other tasks that require controlled pixel blending, including certain cases of anti-aliasing.
Details about those features from GTX 980 whitepaper:
Raster Ordered View
To ensure that rendering results are predictable, the DX API has always specified “in order” processing
rules for the raster pipeline, in particular the Color and Z units (“ROP”). Given two triangles sent to the
GPU in order—first triangle “A,” then “B”—that touch the same XY screen location, the GPU hardware
guarantees that triangle “A” will blend its color result before “B” blends it. Special interlock hardware in
the ROP is responsible for enforcing this ordering requirement.
DX11 introduced the capability for the pixel shader to bind “Unordered Access Views” of color and Z
buffers, and read and write arbitrary locations within those buffers. However as the name implies, there
is no processing order guarantee when multiple pixel shaders are accessing the same UAV.
The next generation DX API introduces the concept of a “Raster Ordered View,” which supports the
same guaranteed processing order that has traditionally been supported by Z and Color ROP units.
Specifically, given two shaders A and B, each associated with the same raster X and Y, hardware must
guarantee that shader A completes all of its accesses to the ROV before shader B makes an access.
To support Raster Ordered View, Maxwell adds a new interlock unit in the shader with similar
functionality to the unit in ROP. When shaders run with access to a ROV enabled, the interlock unit is responsible for tracking the XY of all active pixel shaders and blocking conflicting shaders from running simultaneously.
One potential application for Raster Ordered View is order independent transparency rendering
algorithms, which handle the case of an application that is unable to pre-sort its transparent geometry
by instead having the pixel shader maintain a sorted list of transparent fragments per pixel.