[Website] ROV availability correction

_posts/2021-04-27-leaving-no-pixel-behind-new-render-target-cache-3x3-resolution-scaling.md

@@ -250,7 +250,7 @@ Later, a special path was added for using 24-bit floating-point depth directly,
     *   Rounding conversion can round in both directions (specifically, to the nearest even), but this results in conservative depth testing being unusable, and completely disables early depth testing — and all the pixel shading, which may include lighting or other expensive effects, has to be performed even if the pixel is behind a wall.
 *   With MSAA, unlike color, depth is calculated separately for every sample — otherwise anti-aliasing could only work on polygon edges, but not on geometry intersections. But in order to convert the depth value, we need to know it in the pixel shader — but since it can be different in each sample, the shader needs to be executed for individual samples rather than the whole pixel, doubling or quadrupling _all the pixel shading work_ — including all the lighting and texturing — even though the color output will be the same anyway in the end.
 
-There’s one ultimate sidestep solution for all the pixel format accuracy that was also implemented in Xenia — a **completely custom implementation of all color writing and depth/stencil logic** of the console using the **rasterizer-ordered views (ROV)** feature of Direct3D, also known as **Intel PixelSync,** or, in Vulkan and OpenGL, **fragment shader interlock**. This is that “positive consequence” of using Direct3D 12 in the new Xenia’s GPU subsystem: rasterizer-ordered views have been a part of Direct3D 12 from the beginning, but Vulkan only got the VK_EXT_fragment_shader_interlock extension in 2019 — more than half a year after Xenia started using them! And even still, one of the major PC GPU vendors — AMD — only implements them in Direct3D 12…
+There’s one ultimate sidestep solution for all the pixel format accuracy that was also implemented in Xenia — a **completely custom implementation of all color writing and depth/stencil logic** of the console using the **rasterizer-ordered views (ROV)** feature of Direct3D, also known as **Intel PixelSync,** or, in Vulkan and OpenGL, **fragment shader interlock**. This is that “positive consequence” of using Direct3D 12 in the new Xenia’s GPU subsystem: rasterizer-ordered views have been a part of Direct3D 12 from the beginning, but Vulkan only got the VK_EXT_fragment_shader_interlock extension in 2019 — more than half a year after Xenia started using them! And even still, one of the major PC GPU vendors — AMD — only implements them in Direct3D…
 
 Rasterizer-ordered views (of resources, such as textures or buffers) are a hardware feature **invented by** the often unfairly forgotten player in the GPU industry **Intel** — we’re extremely happy to see them enter the discrete GPU market and wish X<sup>e</sup> graphics the best! — that allows **pixel shaders to perform complex** (beyond primitive atomic operations)**, arbitrary read–modify–write operations**, often performed in programmable blending (which is very similar to what Xenia is doing) and order-independent transparency implementations, **in an orderly way**.