Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Errors from VVL on Nvidia #3778

Open
dudochkin-victor opened this issue Jun 21, 2021 · 10 comments
Open

Errors from VVL on Nvidia #3778

dudochkin-victor opened this issue Jun 21, 2021 · 10 comments
Labels
backend: Vulkan client: request feature request from a known client type: bug

Comments

@dudochkin-victor
Copy link

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)
@dudochkin-victor dudochkin-victor changed the title Errors from VVL jn Nvidia Errors from VVL on Nvidia Jun 21, 2021
@kvark
Copy link
Member

kvark commented Jun 21, 2021

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

@kvark kvark added backend: Vulkan client: request feature request from a known client type: bug labels Jun 21, 2021
@cwfitzgerald
Copy link
Member

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

@kvark
Copy link
Member

kvark commented Jun 21, 2021

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
Copy link
Author

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
Copy link
Author

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
Copy link
Member

kvark commented Jun 21, 2021

What's the version of your validation layers?

@dudochkin-victor
Copy link
Author

Vulkan sdk version 1.2.170

@kvark
Copy link
Member

kvark commented Jun 21, 2021

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
Copy link
Author

dudochkin-victor commented Jun 22, 2021

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
Copy link
Member

kvark commented Jun 22, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend: Vulkan client: request feature request from a known client type: bug
Projects
None yet
Development

No branches or pull requests

3 participants