Errors from VVL on Nvidia

[dudochkin-victor]

Short info header:

• GFX version: 0.9.0
• OS: Linux
• GPU: GeForce GTX 1050/PCIe/SSE2 with proprietary drivers (NVIDIA 460.67)

I want to thank you for a great job. But i have some warnings when use wgpu.
It looks like it is a gfx_backend_vulkan error. I did a little research on this bug and VVL reviews. But I tried to implement some logic with ash and I don't have these warnings in my production application.

So I think this is not a VVL and Nvidia problem. Can you fix this or disable these warnings that appear on every frame?

[2021-06-21T05:22:13Z ERROR gfx_backend_vulkan] 
    VALIDATION [VUID-VkRenderPassBeginInfo-framebuffer-03212 (0xd883b436)] : Validation Error: [ VUID-VkRenderPassBeginInfo-framebuffer-03212 ] Object 0: handle = 0x180000000018, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0xd883b436 | vkCmdBeginRenderPass(): Image view #0 created from an image subresource with height set as 800, but image info #0 used to create the framebuffer had height set as 600 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 a height equal to the height member of the corresponding element of VkFramebufferAttachmentsCreateInfo::pAttachmentImageInfos used to create framebuffer (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-VkRenderPassBeginInfo-framebuffer-03212)
    object info: (type: RENDER_PASS, hndl: 0x180000000018)

[kvark]

Thank you for filing!
Could you record an API trace for us to reproduce this?

[cwfitzgerald]

Isn't this just the imageless fb vvl issues we've been seeing forever now?

[kvark]

KhronosGroup/Vulkan-ValidationLayers#2503 was about the fact that the mipmap level dimensions weren't taken into account. So the mismatch would be within the power of two. But this one has 800 versus 600, so it's something else.

[dudochkin-victor]

git clone https://github.com/gfx-rs/gfx.git
git checkout hal-0.9
cd examples
cargo r --bin quad --features=vulkan

 Finished dev [unoptimized + debuginfo] target(s) in 0.12s
     Running `/home/Substrate/wgpu/gfx/target/debug/quad`
AdapterInfo { name: "GeForce GTX 1050", vendor: 4318, device: 7297, device_type: DiscreteGpu }
Memory types: [MemoryType { properties: (empty), heap_index: 1 }, MemoryType { properties: (empty), heap_index: 1 }, MemoryType { properties: (empty), heap_index: 1 }, MemoryType { properties: (empty), heap_index: 1 }, MemoryType { properties: (empty), heap_index: 1 }, MemoryType { properties: (empty), heap_index: 1 }, MemoryType { properties: (empty), heap_index: 1 }, MemoryType { properties: DEVICE_LOCAL, heap_index: 0 }, MemoryType { properties: CPU_VISIBLE | COHERENT, heap_index: 1 }, MemoryType { properties: CPU_VISIBLE | COHERENT | CPU_CACHED, heap_index: 1 }, MemoryType { properties: DEVICE_LOCAL | CPU_VISIBLE | COHERENT, heap_index: 2 }]
Using sparse resource binding
formats: Some([Bgra8Unorm, Bgra8Srgb])
SwapchainConfig { present_mode: FIFO, composite_alpha_mode: OPAQUE, format: Bgra8Srgb, extent: Extent2D { width: 1024, height: 768 }, image_count: 3, image_layers: 1, image_usage: COLOR_ATTACHMENT }
[2021-06-21T16:03:02Z ERROR gfx_backend_vulkan] 
    VALIDATION [VUID-VkRenderPassBeginInfo-framebuffer-03212 (0xd883b436)] : Validation Error: [ VUID-VkRenderPassBeginInfo-framebuffer-03212 ] Object 0: handle = 0x190000000019, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0xd883b436 | vkCmdBeginRenderPass(): Image view #0 created from an image subresource with height set as 1024, but image info #0 used to create the framebuffer had height set as 768 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 a height equal to the height member of the corresponding element of VkFramebufferAttachmentsCreateInfo::pAttachmentImageInfos used to create framebuffer (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-VkRenderPassBeginInfo-framebuffer-03212)
    object info: (type: RENDER_PASS, hndl: 0x190000000019)
    
resized to PhysicalSize { width: 1024, height: 768 }
SwapchainConfig { present_mode: FIFO, composite_alpha_mode: OPAQUE, format: Bgra8Srgb, extent: Extent2D { width: 1024, height: 768 }, image_count: 3, image_layers: 1, image_usage: COLOR_ATTACHMENT }
[2021-06-21T16:03:02Z ERROR gfx_backend_vulkan] 
    VALIDATION [VUID-VkRenderPassBeginInfo-framebuffer-03212 (0xd883b436)] : Validation Error: [ VUID-VkRenderPassBeginInfo-framebuffer-03212 ] Object 0: handle = 0x190000000019, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0xd883b436 | vkCmdBeginRenderPass(): Image view #0 created from an image subresource with height set as 1024, but image info #0 used to create the framebuffer had height set as 768 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 a height equal to the height member of the corresponding element of VkFramebufferAttachmentsCreateInfo::pAttachmentImageInfos used to create framebuffer (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-VkRenderPassBeginInfo-framebuffer-03212)
    object info: (type: RENDER_PASS, hndl: 0x190000000019)
    
[2021-06-21T16:03:02Z ERROR gfx_backend_vulkan] 
    VALIDATION [VUID-VkRenderPassBeginInfo-framebuffer-03212 (0xd883b436)] : Validation Error: [ VUID-VkRenderPassBeginInfo-framebuffer-03212 ] Object 0: handle = 0x190000000019, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0xd883b436 | vkCmdBeginRenderPass(): Image view #0 created from an image subresource with height set as 1024, but image info #0 used to create the framebuffer had height set as 768 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 a height equal to the height member of the corresponding element of VkFramebufferAttachmentsCreateInfo::pAttachmentImageInfos used to create framebuffer (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-VkRenderPassBeginInfo-framebuffer-03212)
    object info: (type: RENDER_PASS, hndl: 0x190000000019)

seems its happen inside gfx-rs

[dudochkin-victor]

OK. I resized the "quad" exmaple window to 512x512. It seems to have been a power of two problem. And there are no more warnings. Any ideas how to fix this problem? Wait for updates from KhronosGroup or some other options?

[kvark]

What's the version of your validation layers?

[dudochkin-victor]

Vulkan sdk version 1.2.170

[kvark]

Interesting. I just tested this on 1050 GTX / Linux, and not seeing any validation errors. Current version of "vulkan-validation-layers" package is 1.2.170.0. Not sure how to investigate this without a repro :/

[dudochkin-victor]

Maybe you have your own settings for the validation layer? I can definitely upgrade VVL to 1.2.179. I have done additional research.

git clone https://github.com/sotrh/learn-wgpu.git
cd learn-wgpu
cargo run --bin tutorial2-swapchain 

User generated textures do not exist (as I know, mipmaps should not be generated). But I have the same problems.
As far as I know, there are several hacks for working with NPOT textures called upperPowerOfTwo. It might come in handy.

gfx-rs/wgpu#1255

[kvark]

Running this doesn't trigger any validation errors for me either. Are you on Wayland, perhaps?

As far as I know, there are several hacks for working with NPOT textures called upperPowerOfTwo. It might come in handy.

this isn't about NPOT, that other issue was about mipmaps