Multisample rendering

Gaming and Visualization Technologies APIs Vulkan
1

Testing out multisample support with Vulkan i ran into a few problems:

  1. Resolving into a presentable image via subpass, if the view was created with VkImageViewCreateInfo::subresourceRange::layerCount set to the special value VK_REMAINING_ARRAY_LAYERS, indicating all remaining layers, during the recording of the command buffer the call to vkCmdEndRenderPass, which ends the subpass that does the resolve, the driver runs into an endless loop. The disassembler shows that the value is loaded and used in a simple loop (iterating over all layers to resolve i assume), but it was not replaced with the actual layer count nor is the special value checked. Setting the value to 1 solves the issue.

  2. Attachment stores for a render-resolve render pass show buggy behaviour. In detail, a render pass with a single subpass that renders into a multisample color attachment and multisample depth attachment and resolves that color attachment into a presentable image: Intuitively, the color and depth attachment should use clear/dont_care for their load/store ops and the present image should use dont_care/store. But setting the depth attachment to VK_ATTACHMENT_STORE_OP_DONT_CARE results in a flickering image, only the first image rendered is ever presented, all other presents have no effect, the FPS drops significantly, but no call reports an error. Only when i start to clean up will vkDeviceWaitIdle return DEVICE_LOST. Setting VkAttachmentDescription::storeOp of the depth attachment to VK_ATTACHMENT_STORE_OP_STORE solves this issue.

Especially the second one seems weird, as the depth buffer should have no impact on the resolve, and in fact without multisample/resolve, setting the depth attachment to VK_ATTACHMENT_STORE_OP_DONT_CARE while rendering directly to the presentable image works as expected.

Details:

OS: Windows 7 Professional SP1 x64
GPU: GTX 970, Driver 356.43 Vulkan beta driver

Loader: Tested with Vulkan SDK loader (both with and without validation layers) as well as loading the driver myself
Swapchain/Color attachment format: VK_FORMAT_B8G8R8A8_SRGB
Depth attachment format: tested with VK_FORMAT_D24_UNORM_S8_UINT and VK_FORMAT_D32_SFLOAT
Swapchain size: 2
Swapchain mode: mailbox
Multisample count: tested with 2, 4 and 8 samples

Please let me know if you require additional information.

2

Thanks for reporting this.

For 1) there is an issue in the validation layers #38 that manifests itself as and endless loop in the validaytion layers. To rule this out as your issue, do you recall which module you noticed the loop in?

For 2), helpful would be a complete log of the api_dump layer or a renderdoc capture or a repro-app.

I am going to send you a private message with credentials to a temporary SFTP server to which you could upload whichever data from from 2) is convenient for you to provide.

Regards,

Mathias

3

For 1) I can confirm the issue with
a) The Vulkan SDK loader with validation layers
b) The Vulkan SDK loader without validation layers
c) Loading nvoglv64.dll myself, getting vk_icdGetInstanceProcAddr and supplying
vkCreateWin32SurfaceKHR and vkDestroySurfaceKHR myself

   The offending loop is in nvoglv64.dll, in vkCmdEndRenderPass that was loaded from 
   vkGetDeviceProcAddr. I uploaded the disassembly of the function that contains the loop,
   annotated with the observed control flow, as well as call stack and the loaded address
   of nvoglv64.dll.

For 2) I have uploaded api dumps and vktraces of the issue, each rendering 1000 frames. The “store” files
show the working app, using VK_ATTACHMENT_STORE_OP_STORE for the depth attachment. The “dont_care”
files show the issue and come from the same program with only this flag changed to
VK_ATTACHMENT_STORE_OP_DONT_CARE.

I will try to provide a renderdoc capture / repro-app if you cannot locate/repro the issue with this, just let me know.

4

Thanks!

I am able to reproduce issue 2) with your traces and we are investigating.

Regards,

Mathias

5

We found the root cause for issue 1) and have a fix internally. Unfortunately though this didn’t make it into the 356.45 driver we just released. It will be in a future release though.

Thanks for reporting!

You might notice the following in the release notes for 356.45 at https://developer.nvidia.com/vulkan-driver

• Fix device lost issue with some MSAA resolves

This is unlikely though to fix your issue 2) so we’ll keep investigating.

Thanks again for providing bug reports and repros!

Regards,

Mathias

6

Actually, 356.45 should have fixed the issue.

Here is what I get now:

vk_issue_msaa_renderpasses>vkreplay.exe -t issue_2_trace_store.vktrace
Verbose: Enumerated 1 physical devices in the system.
Warning: Reached end of file.

vk_issue_msaa_renderpasses>vkreplay.exe -t issue_2_trace_dont_care.vktrace
Verbose: Enumerated 1 physical devices in the system.
Error: Return value VK_SUCCESS from API call (vkDeviceWaitIdle) does not match return value from trace file VK_ERROR_DEVICE_LOST.
Error: Failed to replay packet_id 27.

Can you please try the driver and see whether issue 2) has been resolved?

Thanks,

Mathias

7

Awesome, i’m glad you could repro and fix both issues.
I can indeed confirm that issue 2 is solved in the new driver 356.45, no device lost and renders like it should.

Thanks for your time :)