{"id":31,"date":"2025-01-25T22:28:04","date_gmt":"2025-01-25T21:28:04","guid":{"rendered":"https:\/\/dreamtalon.net\/?p=31"},"modified":"2025-01-25T22:28:04","modified_gmt":"2025-01-25T21:28:04","slug":"on-using-vrs-as-an-antialiasing-optimization","status":"publish","type":"post","link":"https:\/\/dreamtalon.net\/?p=31","title":{"rendered":"On using VRS as an antialiasing optimization"},"content":{"rendered":"\n
<\/div>\n\n\n\n

An idea I came up with while having few spare moments from work.<\/strong><\/p>\n\n\n\n

How about using VRS as a means to optimize SSAA?
SSAA is known to be very slow due to the need to render 4x more as render targets are 4x larger.
Or rather having 4x more of costly fragment shader invocations – which VRS could in principle mitigate.<\/p>\n\n\n\n

When VRS (Variable Rate Shading) extension is enabled, it permits you to have for example 1 fragment invocation to cover 4 pixels tile.
Which means you could save up some render time by reducing quantity of very costly fragment shader invocations.
I would like to refer to this optimization method as VRSAA.<\/p>\n\n\n\n

Now the details with images and statistics of SSAA and VRS:<\/strong><\/p>\n\n\n\n

\n
\n

rt4x<\/p>\n\n\n\n

\"\"<\/figure>\n<\/div>\n\n\n\n
\n

rt4x vrs<\/p>\n\n\n\n

\"\"<\/figure>\n<\/div>\n<\/div>\n\n\n\n
\n
\n

rt4x -> resize to swapchain<\/p>\n\n\n\n

\"\"<\/figure>\n<\/div>\n\n\n\n
\n

rt4x vrs -> resize to swapchain<\/p>\n\n\n\n

\"\"<\/figure>\n<\/div>\n<\/div>\n\n\n\n

There is hardly any difference visible after resizing and copying render target image onto swapchain image.
Here are same settings but with intermediate FXAA:<\/p>\n\n\n\n

\n
\n

rt4x fxaa<\/p>\n\n\n\n

\"\"<\/figure>\n<\/div>\n\n\n\n
\n

rt4x vrs fxaa<\/p>\n\n\n\n

\"\"<\/figure>\n<\/div>\n<\/div>\n\n\n\n
\n
\n

rt4x fxaa -> resize to swapchain<\/p>\n\n\n\n

\"\"<\/figure>\n<\/div>\n\n\n\n
\n

rt4x vrs fxaa -> resize to swapchain<\/p>\n\n\n\n

\"\"<\/figure>\n<\/div>\n<\/div>\n\n\n\n

Full image with VRSAA + FXAA (click to view)<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The following statistics has been measured on RTX 3070 Laptop, Nvidia driver ver. 565.77 Linux, swapchain resolution 3440×1440.<\/p>\n\n\n\n

Render method<\/td>Average frame time<\/td><\/tr>
No AA<\/td>1.002ms<\/td><\/tr>
FXAA<\/td>1.466ms<\/td><\/tr>
SSAA<\/td>2.392ms<\/td><\/tr>
SSAA + FXAA<\/td>3.846ms<\/td><\/tr>
VRSAA<\/td>2.347ms<\/td><\/tr>
VRSAA + FXAA<\/td>3.704ms<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Overall gain of 0.05ms per frame does not mean much, especially when there is literally 30 draw calls on a scene with very simple fragment shaders.
When extrapolating data, assuimg my frame time was 33ms (30FPS) with SSAA, the benefit gain would be 0.62ms per frame – which in turn would translate as 0.88 FPS improvement.
However, assuming there is more complex scene with more advanced shaders like PBR, then there is a chance the results still could be quite different.<\/p>\n\n\n\n

As a side observation worth mentioning:<\/strong>
If you have FXAA enabled, or possibly other antialiasing method, you could also enable VRS 2×2 tiling, as final result of these two features combined could be very close – to non-observable in scenes with motion (aka regular gameplay).
<\/p>\n\n\n\n

Extra details how to enable VRS in Vulkan:<\/strong><\/p>\n\n\n\n

To enable VRS extension, you have to query and enable the VK_KHR_FRAGMENT_SHADING_RATE_EXTENSION_NAME<\/code> extension on your device.<\/p>\n\n\n\n

uint32_t count = 0;\nvkEnumerateDeviceExtensionProperties( thePhysicalDevice, nullptr, &count, nullptr );\nstd::vector<VkExtensionProperties> existingExtensions( count );\nvkEnumerateDeviceExtensionProperties( thePhysicalDevice, nullptr, &count, existingExtensions.data() )\n\nauto vrscmp = []( const auto& prop )\n{\n    return std::strcmp( prop.extensionName, VK_KHR_FRAGMENT_SHADING_RATE_EXTENSION_NAME ) == 0;\n};\nbool vrsAvailable = std::ranges::find_if( existingExtensions, vrscmp ) != existingExtensions.end();\n\nstd::vector<const char*> enableExtensions{ \/* ... other extensions to use ... *\/ };\nif ( vrsAvailable ) enableExtensions.emplace_back( VK_KHR_FRAGMENT_SHADING_RATE_EXTENSION_NAME );<\/code><\/pre>\n\n\n\n
If the VRS extension is present, you have to pass VkPhysicalDeviceFragmentShadingRateFeaturesKHR<\/code> structure as part of VkDeviceCreateInfo::pNext<\/code> field (or chain of .pNext<\/code> fields in subsequent structs).<\/p>\n\n\n\n
VkPhysicalDeviceFragmentShadingRateFeaturesKHR vrsInfo{\n    .sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_FEATURES_KHR,\n    .pipelineFragmentShadingRate = VK_TRUE,\n    .primitiveFragmentShadingRate = VK_TRUE,\n    .attachmentFragmentShadingRate = VK_TRUE,\n};\n\nVkDeviceCreateInfo deviceCreateInfo{\n    .sType = VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO,\n    .pNext = vrsAvailable ? &vrsInfo : nullptr, \/* ... nullptr or other create infos you wish ... *\/\n    \/* ... rest of your device create info fields ... *\/\n};\nvkCreateDevice( thePhysicalDevice, &deviceCreateInfo, nullptr, &theLogicalDevice );<\/code><\/pre>\n\n\n\n
Now the path diverges what you can do. You can do either, or both if you desire:<\/p>\n\n\n\n