Nsight 2024.1.1.0 is issuing incorrect validation error


There is an annoying Vulkan false positive validation error on Nsight 2024.1.1.0
The issue is fully documented here:

Hi megavlad,

I am sorry for any inconvenience you have encountered. Could you please provide a simple example that would allow us to reproduce the issue? This will help us in investigating and resolving the problem more efficiently.


Could I create a Vulkan application specifically to reproduce this issue? I don’t have the bandwidth to do that. However, there should be enough info in the linked thread to replicate this problem. If there is something that you’re unclear about, in order to recreate it, please ask.

Hi megavlad,

Maybe you can launch your app with Frame Debug activity and get the serialization capture (by click Export as C++ Capture), the captured project might be able to reproduce the issue. We can use that to do some investigation.


NsightCapture.zip (3.3 MB)

Capture attached

Hi megavlad,

I checked the source code within NsightCapture.zip, according to your description in github.com, the usage difference happens between Render Pass and Frame buffer, let us talk based on the code in the NsightCapture.zip.


It’s a match in the source code between render pass and frame buffer, but the project will still show error:


but the VkFramebuffer was created with vkFramebufferAttachmentsCreateInfo::pAttachmentImageInfos[1].usage = VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT|VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT|VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT.

There is a redundant VK_IMAGE_USAGE_TRANSFER_DST_BIT here for render pass. I am sorry but it might not be an issue from Nsight Graphics since the app is not launched from Nsight Graphics, I meet the error while run it directly.


Sir, with due respect, I don’t believe that’s a correct assessment of the problem.

  1. That error comes from the output of a C++ dump that the Nsight tool created. That is, Nsight had to use its own internal state in order to create that C++ dump. If its internal state is incorrect, then dump will be, too.

  2. That dump is not the application that I’m working on. An error there does not mean an error on my app.

It’s easy to miss the validation error on the linked issue, as it is hidden in a dropdown. So, I’m pasting it here, to make sure it is visible.

Notice the mismatched flags between the framebuffer and the renderpass. I have traced this in my code in every way, and I’m positive those flags are correctly issued.

>> Validation Error: [ VUID-VkRenderPassBeginInfo-framebuffer-04627 ] 
Object 0: handle = 0x1e33d413d70, name = gui-only:RP:0, type = VK_OBJECT_TYPE_RENDER_PASS; 
Object 1: handle = 0x1e33d472820, name = FB:0, type = VK_OBJECT_TYPE_FRAMEBUFFER; 
Object 2: handle = 0x1e33c3c0dd0, name = pid:1;view;Color, type = VK_OBJECT_TYPE_IMAGE_VIEW; 
Object 3: handle = 0x1e33be26eb0, name = pid:1;buf;Color, type = VK_OBJECT_TYPE_IMAGE; 
| MessageID = 0x45125641 | 

pRenderPassBegin->pNext<VkRenderPassAttachmentBeginInfo>.pAttachments[1].usage is 

but the VkFramebuffer was created with vkFramebufferAttachmentsCreateInfo::pAttachmentImageInfos[1].usage = 

 The Vulkan spec states: If framebuffer was created with a VkFramebufferCreateInfo::flags value that included VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT, 
 each element of the pAttachments member of a VkRenderPassAttachmentBeginInfo structure included in the pNext chain must be a VkImageView with an 
 inherited usage equal to the usage member of the corresponding element of VkFramebufferAttachmentsCreateInfo::pAttachmentImageInfos used to create framebuffer 

The issues, as I see it:

  1. The flags TRANSFER_SRC and TRANSFER_DST are being added to the color image. My app is not doing that. The app does add those flags to the -Surface- image, but not to the image mentioned in the error.

  2. The TRANSIENT flag is being dropped.

Since the TRANSFER_SRC and TRANSFER_DST flags are also being added to the framebuffer, I don’t think they would actually cause a validation error, since they would match the image/view flags. Although I don’t know where those flags are coming from, I think the culprit for the validation error is the TRANSIENT flag being dropped in the RenderPass, and thus not matching the framebuffer. My stance is that’s happening within Nsight, either by the app or by some extra validation layer(s) that it loads, or whatever.

Attached is an API dump that causes the validation error. Search for this string there:

You should be able to find the place where the images are created, and from there match the framebuffer and renderpass creation. You should be able verify yourself that they are correct.

Additionally, here is an image from within Nsight itself. It displays the flags as they should be, while simultaneously issuing the validation error and showing the wrong values for them.

The error in image form:

API dump attached
api_dump.zip (1.1 MB)

Hi megavlad,

I double checked the codes in the NsightCapture.zip, I am sorry that I was wrong about the redundant VK_IMAGE_USAGE_TRANSFER_DST_BIT was added while call VulkanReplay_CreateImage, it doesn’t exist while define the structures.

Yes, I think I can reproduce your issue, the key here I think is the missing of VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT. I will create some internal case to track this.


Thank you

Hi megavlad,

The issue has been fixed and next release of Nsight Graphics will pick the fix.