Android is enabling a host of useful new Vulkan extensions for mobile. These new extensions are set to improve the state of graphics APIs for modern applications, enabling new use cases and changing how developers can design graphics renderers going forward. I have already provided information about ‘maintenance extensions’. However, another important extension that I explore in this blog is ‘legacy support extensions’.
Vulkan is increasingly being used as a portable “HAL”. The power and flexibility of the API allows for great layered implementations. There is a lot of effort spent in the ecosystem enabling legacy graphics APIs to run efficiently on top of Vulkan. The bright future for driver developers is a world where GPU drivers only implement Vulkan, and where legacy APIs can be implemented on top of that driver.
To that end, there are several features which are generally considered backwards today. They should not be used in new applications unless absolutely required. These extensions exist to facilitate old applications which need to keep running through API translation layers such as ANGLE, DXVK, Zink, and so on.
Speaking the name of this extension causes the general angst level to rise in a room of driver developers. In the world of Direct3D, this feature is also known as stream-out.
The core feature of this extension is that whenever you render geometry, you can capture the resulting geometry data (position and vertex outputs) into a buffer. The key complication from an implementation point of view is that the result is ordered. This means there is no 1:1 relation for input vertex to output data since this extension is supposed to work with indexed rendering, as well as strip types (and even geometry shaders and tessellation, oh my!).
This feature was invented in a world before compute shaders were conceived. The only real method to perform buffer <-> buffer computation was to make use of transform feedback, vertex shaders and rasterizationDiscard. Over time, the functionality of Transform Feedback was extended in various ways, but today it is essentially obsoleted by compute shaders.
There are, however, two niches where this extension still makes sense - graphics debuggers and API translation layers. Transform Feedback is extremely difficult to emulate in the more complicated cases.
In vertex-like shader stages, you need to set up which vertex outputs to capture to a buffer. The shader itself controls the memory layout of the output data. This is unlike other APIs, where you use the graphics API to specify which outputs to capture based on the name of the variable.
Here is an example Vulkan GLSL shader:
#version 450 layout(xfb_stride = 32, xfb_offset = 0, xfb_buffer = 0, location = 0) out vec4 vColor; layout(xfb_stride = 32, xfb_offset = 16, xfb_buffer = 0, location = 1) out vec4 vColor2; layout(xfb_buffer = 1, xfb_stride = 16) out gl_PerVertex { layout(xfb_offset = 0) vec4 gl_Position; }; void main() { gl_Position = vec4(1.0); vColor = vec4(2.0); vColor2 = vec4(3.0); }
The resulting SPIR-V will then look something like:
Capability TransformFeedback ExecutionMode 4 Xfb Decorate 8(gl_PerVertex) Block Decorate 10 XfbBuffer 1 Decorate 10 XfbStride 16 Decorate 17(vColor) Location 0 Decorate 17(vColor) XfbBuffer 0 Decorate 17(vColor) XfbStride 32 Decorate 17(vColor) Offset 0 Decorate 20(vColor2) Location 1 Decorate 20(vColor2) XfbBuffer 0 Decorate 20(vColor2) XfbStride 32 Decorate 20(vColor2) Offset 16
Once we have a pipeline which can emit transform feedback data, we need to bind buffers:
vkCmdBindTransformFeedbackBuffersEXT(cmd, firstBinding, bindingCount, pBuffers, pOffsets, pSizes);
To enable a buffer to be captured, VK_BUFFER_USAGE_TRANSFORM_FEEDBACK_BUFFER_BIT_EXT is used.
Once we know where to write the vertex output data, we will begin and end captures. This needs to be done inside a render pass:
vkCmdBeginTransformFeedbackEXT(cmd, firstCounterBuffer, counterBufferCount, pCounterBuffers, pCounterBufferOffsets);
A counter buffer allows us to handle scenarios where we end a transform feedback and continue capturing later. We would not necessarily know how many bytes were written by the last transform feedback, so it is critical that we can let the GPU maintain a byte counter for us.
vkCmdDraw(cmd, …); vkCmdDrawIndexed(cmd, …); Then we can start rendering. Vertex outputs are captured to the buffers in-order. vkCmdEndTransformFeedbackEXT(cmd, firstCounterBuffer, counterBufferCount, pCounterBuffers, pCounterBufferOffsets);
Once we are done capturing, we end the transform feedback and, with the counter buffers, we can write the new buffer offsets into the counter buffer.
This feature is a precursor to the more flexible indirect draw feature we have in Vulkan, but there was a time when this feature was the only efficient way to render transform feedbacked outputs. The fundamental problem is that we do not necessarily know exactly how many primitives have been rendered. Therefore, to avoid stalling the CPU, it was required to be able to indirectly render the results with a special purpose API.
vkCmdDrawIndirectByteCountEXT(cmd, instanceCount, firstInstance, counterBuffer, counterBufferOffset, counterOffset, vertexStride);
This works similarly to a normal indirect draw call, but instead of providing a vertex count, we give it a byte count and let the GPU perform the divide instead. This is nice, as otherwise we would have to dispatch a tiny compute kernel that converts a byte count to an indirect draw.
The offset counter is sort of like a query, but if the transform feedback buffers overflow, any further writes are ignored. The VK_QUERY_TYPE_TRANSFORM_FEEDBACK_STREAM_EXT queries how many primitives were generated. It also lets you query how many primitives were attempted to be written. This makes it possible to detect overflow if that is desirable.
Line rasterization is a tricky subject and is not normally used for gaming applications since they do not scale with resolution and their exact behavior is not consistent across all GPU implementations.
In the world of CAD, however, this feature is critical, and older OpenGL APIs had extensive support for quite fancy line rendering methods. This extension essentially brings back those workstation features. Advanced line rendering can occasionally be useful for debug tooling and visualization as well.
typedef struct VkPhysicalDeviceLineRasterizationFeaturesEXT { VkStructureType sType; void* pNext; VkBool32 rectangularLines; VkBool32 bresenhamLines; VkBool32 smoothLines; VkBool32 stippledRectangularLines; VkBool32 stippledBresenhamLines; VkBool32 stippledSmoothLines; } VkPhysicalDeviceLineRasterizationFeaturesEXT;
This extension supports a lot of different feature bits. I will try to summarize what they mean below.
When rendering normal lines in core Vulkan, there are two ways lines can be rendered. If VkPhysicalDeviceLimits::strictLines is true, a line is rendered as if the line is a true, oriented rectangle. This is essentially what you would get if you rendered a scaled and rotated rectangle yourself. The hardware just expands the line along the perpendicular axis of the line axis.
In non-strict rendering, we get a parallelogram. The line is extended either in X or Y directions.
(From Vulkan specification)
Bresenham lines reformulate the line rendering algorithm where each pixel has a diamond shaped area around the pixel and coverage is based around intersection and exiting the area. The advantage here is that rendering line strips avoids overdraw. Rectangle or parallelogram rendering does not guarantee this, which matters if you are rendering line strips with blending enabled.
Smooth lines work like rectangular lines, except the implementation can render a little further out to create a smooth edge. Exact behavior is also completely unspecified, and we find the only instance of the word “aesthetic” in the entire specification, which is amusing. This is a wonderfully vague word to see in the Vulkan specification, which is otherwise no-nonsense normative.
This feature is designed to work in combination with alpha blending since the smooth coverage of the line rendering is multiplied into the alpha channel of render target 0’s output.
A “classic” feature that will make most IHVs cringe a little. When rendering a line, it is possible to mask certain pixels in a pattern. A counter runs while rasterizing pixels in order and with line stipple you control a divider and mask which generates a fixed pattern for when to discard pixels. It is somewhat unclear if this feature is really needed when it is possible to use discard in the fragment shader, but alas, legacy features from the early 90s are sometimes used. There were no shaders back in those days.
When creating a graphics pipeline, you can pass in some more data in pNext of rasterization state:
typedef struct VkPipelineRasterizationLineStateCreateInfoEXT { VkStructureType sType; const void* pNext; VkLineRasterizationModeEXT lineRasterizationMode; VkBool32 stippledLineEnable; uint32_t lineStippleFactor; uint16_t lineStipplePattern; } VkPipelineRasterizationLineStateCreateInfoEXT; typedef enum VkLineRasterizationModeEXT { VK_LINE_RASTERIZATION_MODE_DEFAULT_EXT = 0, VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT = 1, VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT = 2, VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT = 3, } VkLineRasterizationModeEXT;
If line stipple is enabled, the line stipple factors can be baked into the pipeline, or be made a dynamic pipeline state using VK_DYNAMIC_STATE_LINE_STIPPLE_EXT.
In the case of dynamic line stipple, the line stipple factor and pattern can be modified dynamically with:
vkCmdSetLineStippleEXT(cmd, factor, pattern);
In OpenGL and OpenGL ES, we have support for 8-bit index buffers. Core Vulkan and Direct3D however only support 16-bit and 32-bit index buffers. Since emulating index buffer formats is impractical with indirect draw calls being a thing, we need to be able to bind 8-bit index buffers. This extension does just that.
This is probably the simplest extension we have look at so far:
vkCmdBindIndexBuffer(cmd, indexBuffer, offset, VK_INDEX_TYPE_UINT8_EXT); vkCmdDrawIndexed(cmd, …);
I have been through the 'maintenance' and 'legacy support' extensions that are part of the new Vulkan extensions for mobile. In the next three blogs, I will go through what I see as the 'game-changing' extensions from Vulkan - the three that will help to transform your games during the development process.
Learn more about the new Vulkan extensions