search

gfx-rs / gfx

[maintenance mode] A low-overhead Vulkan-like GPU API for Rust.
http://gfx-rs.github.io/
Apache License 2.0
5.35k stars 551 forks source link

Errors from VVL on Nvidia #3778

Open dudochkin-victor opened 3 years ago

dudochkin-victor commented 3 years ago

Short info header:

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 commented 3 years ago

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

cwfitzgerald commented 3 years ago

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

kvark commented 3 years ago

https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

What's the version of your validation layers?

dudochkin-victor commented 3 years ago

Vulkan sdk version 1.2.170

kvark commented 3 years ago

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 commented 3 years ago

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.

https://github.com/gfx-rs/wgpu/issues/1255

kvark commented 3 years ago

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