Jump to content

New Vulkan Extensions for Mobile: Maintenance Extensions

STF News

Recommended Posts


The Samsung Developers team works with many companies in the mobile and gaming ecosystems. We're excited to support our partner, Arm, as they bring timely and relevant content to developers looking to build games and high-performance experiences. This Vulkan Extensions series will help developers get the most out of the new and game-changing Vulkan extensions on Samsung mobile devices.

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. In particular, in Android R, there has been a whole set of Vulkan extensions added. These extensions will be available across various Android smartphones, including the Samsung Galaxy S21, which was recently launched on 14 January. Existing Samsung Galaxy S models, such as the Samsung Galaxy S20, also allow upgrades to Android R.

One of these new Vulkan extensions for mobile are ‘maintenance extensions’. These plug up various holes in the Vulkan specification. Mostly, a lack of these extensions can be worked around, but it is annoying for application developers to do so. Having these extensions means less friction overall, which is a very good thing.


This extension is a quiet one, but I still feel it has a lot of impact since it removes a fundamental restriction for applications. Getting to data efficiently is the lifeblood of GPU programming.

One thing I have seen trip up developers again and again are the antiquated rules for how uniform buffers (UBO) are laid out in memory. For whatever reason, UBOs have been stuck with annoying alignment rules which go back to ancient times, yet SSBOs have nice alignment rules. Why?

As an example, let us assume we want to send an array of floats to a shader:

#version 450

layout(set = 0, binding = 0, std140) uniform UBO
    float values[1024];

layout(location = 0) out vec4 FragColor;
layout(location = 0) flat in int vIndex;

void main()
    FragColor = vec4(values[vIndex]);

If you are not used to graphics API idiosyncrasies, this looks fine, but danger lurks around the corner. Any array in a UBO will be padded out to have 16 byte elements, meaning the only way to have a tightly packed UBO is to use vec4 arrays. Somehow, legacy hardware was hardwired for this assumption. SSBOs never had this problem.

std140 vs std430

You might have run into these weird layout qualifiers in GLSL. They reference some rather old GLSL versions. std140 refers to GLSL 1.40, which was introduced in OpenGL 3.1, and it was the version uniform buffers were introduced to OpenGL.

The std140 packing rules define how variables are packed into buffers. The main quirks of std140 are:

  • Vectors are aligned to their size. Notoriously, a vec3 is aligned to 16 bytes, which have tripped up countless programmers over the years, but this is just the nature of vectors in general. Hardware tends to like aligned access to vectors.
  • Array element sizes are aligned to 16 bytes. This one makes it very wasteful to use arrays of float and vec2.

The array quirk mirrors HLSL’s cbuffer. After all, both OpenGL and D3D mapped to the same hardware. Essentially, the assumption I am making here is that hardware was only able to load 16 bytes at a time with 16 byte alignment. To extract scalars, you could always do that after the load.

std430 was introduced in GLSL 4.30 in OpenGL 4.3 and was designed to be used with SSBOs. std430 removed the array element alignment rule, which means that with std430, we can express this efficiently:

#version 450

layout(set = 0, binding = 0, std430) readonly buffer SSBO
    float values[1024];

layout(location = 0) out vec4 FragColor;
layout(location = 0) flat in int vIndex;

void main()
    FragColor = vec4(values[vIndex]);

Basically, the new extension enables std430 layout for use with UBOs as well.

#version 450
#extension GL_EXT_scalar_block_layout : require

layout(set = 0, binding = 0, std430) uniform UBO
    float values[1024];

layout(location = 0) out vec4 FragColor;
layout(location = 0) flat in int vIndex;

void main()
    FragColor = vec4(values[vIndex]);

Why not just use SSBOs then?

On some architectures, yes, that is a valid workaround. However, some architectures also have special caches which are designed specifically for UBOs. Improving memory layouts of UBOs is still valuable.


The Vulkan GLSL extension which supports std430 UBOs goes a little further and supports the scalar layout as well. This is a completely relaxed layout scheme where alignment requirements are essentially gone, however, that requires a different Vulkan extension to work.


Depth-stencil images are weird in general. It is natural to think of these two aspects as separate images. However, the reality is that some GPU architectures like to pack depth and stencil together into one image, especially with D24S8 formats.

Expressing image layouts with depth and stencil formats have therefore been somewhat awkward in Vulkan, especially if you want to make one aspect read-only and keep another aspect as read/write, for example.

In Vulkan 1.0, both depth and stencil needed to be in the same image layout. This means that you are either doing read-only depth-stencil or read/write depth-stencil. This was quickly identified as not being good enough for certain use cases. There are valid use cases where depth is read-only while stencil is read/write in deferred rendering for example.

Eventually, VK_KHR_maintenance2 added support for some mixed image layouts which lets us express read-only depth, read/write stencil, and vice versa:



Usually, this is good enough, but there is a significant caveat to this approach, which is that depth and stencil layouts must be specified and transitioned together. This means that it is not possible to render to a depth aspect, while transitioning the stencil aspect concurrently, since changing image layouts is a write operation. If the engine is not designed to couple depths and stencil together, it causes a lot of friction in implementation.

What this extension does is completely decouple image layouts for depth and stencil aspects and makes it possible to modify the depth or stencil image layouts in complete isolation. For example:

    VkImageMemoryBarrier barrier = {…};

Normally, we would have to specify both DEPTH and STENCIL aspects for depth-stencil images. Now, we can completely ignore what stencil is doing and only modify depth image layout.

    barrier.subresourceRange.aspectMask = VK_IMAGE_ASPECT_DEPTH_BIT;

Similarly, in VK_KHR_create_renderpass2, there are extension structures where you can specify stencil layouts separately from the depth layout if you wish.

typedef struct VkAttachmentDescriptionStencilLayout {
    VkStructureType sType;
    void*          pNext;
    VkImageLayout      stencilInitialLayout;
    VkImageLayout      stencilFinalLayout;
} VkAttachmentDescriptionStencilLayout;

typedef struct VkAttachmentReferenceStencilLayout {
    VkStructureType sType;
    void*          pNext;
    VkImageLayout  stencilLayout;
} VkAttachmentReferenceStencilLayout;

Like image memory barriers, it is possible to express layout transitions that only occur in either depth or stencil attachments.


Each core Vulkan version has targeted a specific SPIR-V version. For Vulkan 1.0, we have SPIR-V 1.0. For Vulkan 1.1, we have SPIR-V 1.3, and for Vulkan 1.2 we have SPIR-V 1.5.

SPIR-V 1.4 was an interim version between Vulkan 1.1 and 1.2 which added some nice features, but the usefulness of this extension is largely meant for developers who like to target SPIR-V themselves. Developers using GLSL or HLSL might not find much use for this extension. Some highlights of SPIR-V 1.4 that I think are worth mentioning are listed here.

OpSelect between composite objects

OpSelect before SPIR-V 1.4 only supports selecting between scalars and vectors. SPIR-V 1.4 thus allows you to express this kind of code easily with a simple OpSelect:

    MyStruct s = cond ? MyStruct(1, 2, 3) : MyStruct(4, 5, 6);


There are scenarios in high-level languages where you load a struct from a buffer and then place it in a function variable. If you have ever looked at SPIR-V code for this kind of scenario, glslang would copy each element of the struct one by one, which generates bloated SPIR-V code. This is because the struct type that lives in a buffer and a struct type for a function variable are not necessarily the same. Offset decorations are the major culprits here. Copying objects in SPIR-V only works when the types are exactly the same, not “almost the same”. OpCopyLogical fixes this problem where you can copy objects of types which are the same except for decorations.

Advanced loop control hints

SPIR-V 1.4 adds ways to express partial unrolling, how many iterations are expected, and such advanced hints, which can help a driver optimize better using knowledge it otherwise would not have. There is no way to express these in normal shading languages yet, but it does not seem difficult to add support for it.

Explicit look-up tables

Describing look-up tables was a bit awkward in SPIR-V. The natural way to do this in SPIR-V 1.3 is to declare an array with private storage scope with an initializer, access chain into it and load from it. However, there was never a way to express that a global variable is const, which relies on compilers to be a little smart. As a case study, let us see what glslang emits when using Vulkan 1.1 target environment:

#version 450

layout(location = 0) out float FragColor;
layout(location = 0) flat in int vIndex;

const float LUT[4] = float[](1.0, 2.0, 3.0, 4.0);

void main()
    FragColor = LUT[vIndex];

%float_1 = OpConstant %float 1
%float_2 = OpConstant %float 2
%float_3 = OpConstant %float 3
%float_4 = OpConstant %float 4
%16 = OpConstantComposite %_arr_float_uint_4 %float_1 %float_2 %float_3 %float_4

This is super weird code, but it is easy for compilers to promote to a LUT. If the compiler can prove there are no readers before the OpStore, and only one OpStore can statically happen, compiler can optimize it to const LUT.

%indexable = OpVariable %_ptr_Function__arr_float_uint_4 Function
OpStore %indexable %16
%24 = OpAccessChain %_ptr_Function_float %indexable %index
%25 = OpLoad %float %24

In SPIR-V 1.4, the NonWritable decoration can also be used with Private and Function storage variables. Add an initializer, and we get something that looks far more reasonable and obvious:

OpDecorate %indexable NonWritable
%16 = OpConstantComposite %_arr_float_uint_4 %float_1 %float_2 %float_3 %float_4

// Initialize an array with a constant expression and mark it as NonWritable.
// This is trivially a LUT.
%indexable = OpVariable %_ptr_Function__arr_float_uint_4 Function %16
%24 = OpAccessChain %_ptr_Function_float %indexable %index
%25 = OpLoad %float %24


This extension fixes a hole in Vulkan subgroup support. When subgroups were introduced, it was only possible to use subgroup operations on 32-bit values. However, with 16-bit arithmetic getting more popular, especially float16, there are use cases where you would want to use subgroup operations on smaller arithmetic types, making this kind of shader possible:

#version 450

// subgroupAdd
#extension GL_KHR_shader_subgroup_arithmetic : require

For FP16 arithmetic:

#extension GL_EXT_shader_explicit_arithmetic_types_float16 : require

For subgroup operations on FP16:

#extension GL_EXT_shader_subgroup_extended_types_float16 : require

layout(location = 0) out f16vec4 FragColor;
layout(location = 0) in f16vec4 vColor;

void main()
    FragColor = subgroupAdd(vColor);


In most engines, using VkFramebuffer objects can feel a bit awkward, since most engine abstractions are based around some idea of:

MyRenderAPI::BindRenderTargets(colorAttachments, depthStencilAttachment)

In this model, VkFramebuffer objects introduce a lot of friction, since engines would almost certainly end up with either one of two strategies:

  • Create a VkFramebuffer for every render pass, free later.
  • Maintain a hashmap of all observed attachment and render-pass combinations.

Unfortunately, there are some … reasons why VkFramebuffer exists in the first place, but VK_KHR_imageless_framebuffer at least removes the largest pain point. This is needing to know the exact VkImageViews that we are going to use before we actually start rendering.

With imageless frame buffers, we can defer the exact VkImageViews we are going to render into until vkCmdBeginRenderPass. However, the frame buffer itself still needs to know about certain metadata ahead of time. Some drivers need to know this information unfortunately.

First, we set the VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT flag in vkCreateFramebuffer. This removes the need to set pAttachments. Instead, we specify some parameters for each attachment. We pass down this structure as a pNext:

typedef struct VkFramebufferAttachmentsCreateInfo {
    VkStructureType                        sType;
    const void*                                pNext;
    uint32_t                                   attachmentImageInfoCount;
    const VkFramebufferAttachmentImageInfo*    pAttachmentImageInfos;
} VkFramebufferAttachmentsCreateInfo;

typedef struct VkFramebufferAttachmentImageInfo {
    VkStructureType   sType;
    const void*       pNext;
    VkImageCreateFlags flags;
    VkImageUsageFlags usage;
    uint32_t          width;
    uint32_t          height;
    uint32_t          layerCount;
    uint32_t          viewFormatCount;
    const VkFormat*   pViewFormats;
} VkFramebufferAttachmentImageInfo;

Essentially, we need to specify almost everything that vkCreateImage would specify. The only thing we avoid is having to know the exact image views we need to use.

To begin a render pass which uses imageless frame buffer, we pass down this struct in vkCmdBeginRenderPass instead:

typedef struct VkRenderPassAttachmentBeginInfo {
    VkStructureType   sType;
    const void*       pNext;
    uint32_t          attachmentCount;
    const VkImageView* pAttachments;
} VkRenderPassAttachmentBeginInfo;


Overall, I feel like this extension does not really solve the problem of having to know images up front. Knowing the resolution, usage flags of all attachments up front is basically like having to know the image views up front either way. If your engine knows all this information up-front, just not the exact image views, then this extension can be useful. The number of unique VkFramebuffer objects will likely go down as well, but otherwise, there is in my personal view room to greatly improve things.

In the next blog on the new Vulkan extensions, I explore 'legacy support extensions.'

Follow Up

Thanks to Hans-Kristian Arntzen and the team at Arm for bringing this great content to the Samsung Developers community. We hope you find this information about Vulkan extensions useful for developing your upcoming mobile games.

The Samsung Developers site has many resources for developers looking to build for and integrate with Samsung devices and services. Stay in touch with the latest news by creating a free account or by subscribing to our monthly newsletter. Visit the Marketing Resources page for information on promoting and distributing your apps and games. Finally, our developer forum is an excellent way to stay up-to-date on all things related to the Galaxy ecosystem.

View the full blog at its source

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Topics

    • By STF News
      Samsung Electronics today announced that its 2022 QLED and Lifestyle TVs have been recognized by leading global certification institutes for eye safety and color technology. The news comes as the company announced its newest QLED and Lifestyle TVs at CES 2022.

      The 2022 Samsung Lifestyle TVs won the ‘Eye Care’ Certification from Verband Deutscher Elektrotechniker (VDE) in Germany, one of Europe’s largest technical-scientific associations with more than 36,000 members. The certification applies to Samsung’s 2022 Lifestyle TV models including The Frame, The Serif and The Sero. The screens are evaluated on various categories, including ‘Safety’, ‘Gentle to the eyes’, flicker level, uniformity and color fidelity.
      (From left) Seokwoo Yong, EVP and Head of R&D Team, Visual Display Business at Samsung Electronics and Cherif Kedir, President & CEO of VDE
      The new Lifestyle TVs were assessed for safety from blue light emission and melatonin inhibition levels based on a light hazard classification method set by the International Electrotechnical Commission (IEC). Samsung’s 2022 Lifestyle TVs satisfy the IEC’s standards for screen flickering, which can cause eye fatigue or headache for viewers. They were also recognized for excellence in color fidelity and picture quality uniformity, both elements of which contribute to eye comfort level while watching TV.
      (From left) Seokwoo Yong, EVP and Head of R&D Team, Visual Display Business at Samsung Electronics and Wyatt Brannan, Vice President of North America Consumer, Medical & Information Technology of UL
      Samsung’s 2022 Lifestyle TVs1 were also verified as ‘Glare-Free’ by Underwriters Laboratories (UL), a leading independent safety science company. UL’s verification validates the ‘Glare-Free’ claim by assessing the products against Unified Glare Rating (UGR) testing standard set by the International Commission on Illumination (CIE). Samsung’s new Lifestyle TV models use a new Matte Display with anti-glare, anti-reflection and anti-fingerprint properties to deliver the optimal brightness and provide the best picture quality without glare.
      Reflected Glare, which determines whether the objects on a TV screen are visible even when external light is reflected on the surface Discomfort Glare, which determines whether a TV screen is too bright Disability Glare, which determines whether a TV screen is overly bright when watching TV in a dark room  
      These glare assessments were calculated based on test results of watching TV in both 300 lux, which is equivalent to a brightly lit work area, and in 150 lux, which is usually the value for a dimly lit work area.
      (From left) Seokwoo Yong, EVP and Head of R&D Team, Visual Display Business at Samsung Electronics and Raj Shah, Vice President at Marketing of Pantone
      Additionally, Samsung’s all new 2022 QLED models received the world’s first ‘Pantone Validated’ certification from Pantone, the world-famous brand in the global color industry and creator of the Pantone Matching System (PMS).
      These models receiving this recognition from Pantone include all 20 newly released models – 15 QLED TVs in both 4K and 8K and five monitors. Samsung’s 2022 QLED TV line-up was recognized for its accurate expression of 2,030 Pantone colors and newly added 110 skin tone shades.
      “As TVs become more of an entertainment hub in the home, there’s an increased demand for screens with top-tier picture quality that minimize eye strain,” said Seokwoo Yong, Executive Vice President and Head of R&D Team, Visual Display Business at Samsung Electronics. “This recognition from leading global institutes validates our technology that delivers best-in-class images along with the most comfortable watching experience.”
      1 Applicable to Samsung’s 2022 Lifestyle TVs consisting of The Frame, The Serif and The Sero.
      View the full article
    • By regenitin
      Hello everyone.
      I recently purchased Samsung The Frame 2020 (QA55LS03TAKXXL) in India 2 very important observations from my end.
      I am planning to purchase the Samsung Q600A Soundbar to pair with my TV and wanted to know if my TV supports Q-Symphony. I reached out the support team and they confirmed me that the Q-Symphony function is not a feature of my TV. I wanted to know if Samsung plans to update the operating System to support Q Symphony as this feature is present in Samsung The Frame 2021 which has exact same hardware as Samsung The Frame 2020. Since the support did not have any idea i thought of reaching out to folks on this forum. I am not able to find Amazon Prime Music & Youtube Music apps on the Samsung App Store. These are supposed to be pretty necessary and widely used apps and I am not able to figure out the reason they are not in the store. I would like to know if there are any plans to launch these apps soon. Also let me know if there is any work around to get the apps installed. Thanks in advance for your inputs.
      Best Regards
    • By Alex
      Starting this year, Samsung's Tizen app store is no longer accessible, both to new and existing users. Last year in June, the company closed registrations and made the store available only to existing users and they could only get previously downloaded apps.

      After December 31, 2021, however, the Tizen app store is permanently closed. So in case you are using a Samsung Z series smartphone, it might be time to switch over to Android or iOS. The last Samsung Z4 phone running Tizen OS was released back in 2017 so it was kind of an expected turn of events.
      It seems like the company is dropping its Tizen project after this year's Galaxy Watch4 series is running on Google's Wear OS and all future Galaxy watches will do the same.
      Source: https://www.gsmarena.com/samsung_shuts_down_the_tizen_app_store-news-52598.php
    • By STF News
      Samsung Electronics announced that its 32-inch Odyssey Neo G8 monitor earned a Best of Innovation Award in the Gaming category at CES 2022.
      Samsung’s lineup received 2022 Honoree accolades across the board, including for the 55-inch Odyssey Ark, the 49-inch Odyssey Neo G9, the 32-inch Odyssey Neo G8, the 34-inch Odyssey G8, the 32-inch Smart Monitor M8 and the 32-inch High Resolution Monitor S8. This marks the ninth accolade that Samsung monitors have received at this year’s CES, setting a new record for the lineup at the world’s largest electronics show.
      Sponsored by the CTA, which owns and organizes CES, the CES Innovation Awards program spotlights standout examples of design and engineering across multiple consumer product categories. This marks the sixth straight year that Samsung monitors have earned CES Innovation Awards, solidifying the company’s position as the global leader in the gaming monitor market.
      Check out the infographic below to view this year’s complete list of award-winning monitors.

      View the full article
    • By STF News
      Want to see everything that’s going on at Samsung’s CES booth all in one interactive image? Then look no further!
      In the image below, simply hover the cursor over the product or event you want to know more about, then click. Videos providing more details will play right away, while you can then read articles that feature even more information on the various products and events. The content will continue to be updated as the event goes on.
      Have fun!
      View the full article
  • Create New...