Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
  • Groups
    • Arm Research
    • DesignStart
    • Education Hub
    • Innovation
    • Open Source Software and Platforms
  • Forums
    • AI and ML forum
    • Architectures and Processors forum
    • Arm Development Platforms forum
    • Arm Development Studio forum
    • Arm Virtual Hardware forum
    • Automotive forum
    • Compilers and Libraries forum
    • Graphics, Gaming, and VR forum
    • High Performance Computing (HPC) forum
    • Infrastructure Solutions forum
    • Internet of Things (IoT) forum
    • Keil forum
    • Morello Forum
    • Operating Systems forum
    • SoC Design and Simulation forum
    • 中文社区论区
  • Blogs
    • AI and ML blog
    • Announcements
    • Architectures and Processors blog
    • Automotive blog
    • Graphics, Gaming, and VR blog
    • High Performance Computing (HPC) blog
    • Infrastructure Solutions blog
    • Innovation blog
    • Internet of Things (IoT) blog
    • Mobile blog
    • Operating Systems blog
    • Research Articles
    • SoC Design and Simulation blog
    • Smart Homes
    • Tools, Software and IDEs blog
    • Works on Arm blog
    • 中文社区博客
  • Support
    • Open a support case
    • Documentation
    • Downloads
    • Training
    • Arm Approved program
    • Arm Design Reviews
  • Community Help
  • More
  • Cancel
Arm Community blogs
Arm Community blogs
Graphics, Gaming, and VR blog New Vulkan extensions for mobile: Legacy Support Extensions
  • Blogs
  • Mentions
  • Sub-Groups
  • Tags
  • Jump...
  • Cancel
More blogs in Arm Community blogs
  • AI and ML blog

  • Announcements

  • Architectures and Processors blog

  • Automotive blog

  • Embedded blog

  • Graphics, Gaming, and VR blog

  • High Performance Computing (HPC) blog

  • Infrastructure Solutions blog

  • Internet of Things (IoT) blog

  • Operating Systems blog

  • SoC Design and Simulation blog

  • Tools, Software and IDEs blog

Tell us what you think
Tags
  • mobile
  • Android
  • Mali GPU Tools
  • vulkan
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

New Vulkan extensions for mobile: Legacy Support Extensions

Hans-Kristian Arntzen
Hans-Kristian Arntzen
February 18, 2021

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.

VK_EXT_transform_feedback

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.

Setting up shaders

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
 

Binding transform feedback buffers

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.

Starting and stopping capture

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.

Indirectly drawing transform feedback results

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.

Queries

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.

VK_EXT_line_rasterization

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.

The feature zoo

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.

Rectangular lines vs parallelogram

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

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.

(From Vulkan specification)

Smooth lines

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.

Line stipple

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.

Configuring rasterization pipeline state

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);

VK_EXT_index_type_uint8

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, …);
 

Conclusion

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

Anonymous
Graphics, Gaming, and VR blog
  • Style transfer for graphics post-processing on mobile

    Pavel Rudko
    Pavel Rudko
    This blog explains how developers can implement style transfer for graphics post-processing on mobile, in particular neural style transfer.
    • March 24, 2022
  • Analyzing ray traced content with Arm Mobile Studio

    Geraint North
    Geraint North
    This blog describes how Arm Mobile Studio can analyze ray traced content, with this being showcased via OPPO Find X5 pro smartphones at GDC 2022.
    • March 15, 2022
  • Using Adaptive Performance for the “Amazing Adventures of Dr. Arm”

    Joe Rozek
    Joe Rozek
    This blog explores Unity's Adaptive Performance and how it was applied to an internal Arm gaming title that will be showcased at GDC 2022.
    • March 14, 2022