OpenGL and Vulkan both render line segments as a series of pixels between two points. They differ in which pixels cover the line.
For single sample rendering Vulkan uses an algorithm based on quad coverage. A small shape is extruded around the line segment. Samples covered by the shape then represent the line segment. See the Vulkan spec for more details.
OpenGL‘s algorithm is based on Bresenham's line algorithm. Bresenham’s algorithm selects pixels on the line between the two segment points. Note Bresenham's does not support multisampling. When compared visually you can see the Vulkan line segment rasterization algorithm always selects a superset of the line segment pixels rasterized in OpenGL. See this example:
The OpenGL spec defines a “diamond-exit” rule to select fragments on a line. Please refer to the 2.0 spec section 3.4.1 “Basic Line Segment Rasterization” spec for more details. To implement this rule we inject a small computation to test if a pixel falls within the diamond in the start of the pixel shader. If the pixel fails the diamond test we discard the fragment. Note that we only perform this test when drawing lines. See the section on Shader Compilation for more info. See the below diagram for an illustration of the diamond rule:
We can implement the OpenGL test by checking the intersection of the line and the medial axes of the pixel p
. If the length of the line segment between intersections p
and the point center is greater than a half-pixel for all possible p
then the pixel is not on the segment. To solve for p
we use the pixel center a
given by gl_FragCoord
and the projection of a
onto the line segment b
given by the interpolated gl_Position
. Since gl_Position
is not available in the fragment shader we must add an internal position varying when drawing lines.
The full code derivation is omitted for brevity. It reduces to the following shader snippet:
vec2 b = ((position * 0.5) + 0.5) * gl_Viewport.zw + gl_Viewport.xy; vec2 ba = abs(b - gl_FragCoord.xy); vec2 ba2 = 2.0 * (ba * ba); vec2 bp = ba2 + ba2.yx - ba; if (bp.x > epsilon && bp.y > epsilon) discard;
Note that we must also pass the viewport size as an internal uniform. We use a small epsilon value to correct for cases when the line segment is perfectly parallel or perpendicular to the window. For code please see TranslatorVulkan.cpp under AddLineSegmentRasterizationEmulation
.
The required Vulkan format support tables do not implement the full set of formats needed for OpenGL conformance with extensions. ANGLE emulates missing formats using format overrides and format fallbacks.
An override implements a missing GL format with a required format in all cases. For example, the luminance texture format L8_UNORM
does not exist in Vulkan. We override L8_UNORM
with the required image format R8_UNORM
.
A fallback is one or more non-required formats ANGLE checks for support at runtime. For example, R8_UNORM
is not a required vertex buffer format. Some drivers do support R8_UNORM
for vertex buffers. So at runtime we check for sampled image support and fall back to R32_FLOAT
if R8_UNORM
is not supported.
Overrides and fallbacks are implemented in ANGLE's [Vulkan format table][vk_format_table_autogen.cpp]. The table is auto-generated by gen_vk_format_table.py
. We store the mapping from angle::Format::ID
to VkFormat in vk_format_map.json
. The format map also lists the overrides and fallbacks. To update the tables please modify the format map JSON and then run scripts/run_code_generation.py
.
The vk::Format
class describes the information ANGLE needs for a particular VkFormat
. The ‘ANGLE’ format ID is a reference to the front-end format. The ‘Image’ or ‘Buffer’ format are the native Vulkan formats that implement a particular front-end format for VkImages
and VkBuffers
. For the above example of R8_UNORM
overriding L8_UNORM
, L8_UNORM
is the ANGLE format and R8_UNORM
is the Image format.
For more information please see the source files.