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

[wgpu] Validation error when sampling multisampled texture in capture_hi_res.rs example #462

Closed
mitchmindtree opened this issue Mar 2, 2020 · 4 comments

Comments

@mitchmindtree
Copy link
Member

Some Context

The new capture_hi_res.rs example demonstrates the following steps each frame:

  1. Draw some vector graphics.
  2. Render the vector graphics to a multisampled 4K UHD texture.
  3. Capture the texture and save it to a PNG file.
  4. Write the multisampled 4K texture to the much smaller multisampled window frame texture. This step is the focus of this issue.

During step 4, we use a TextureReshaper to write the larger mulstisampled texture to the smaller multisampled window texture (see here). The TextureReshaper does this by treating the src_texture as a shader input and rendering it with two triangles to the dst_texture. The TextureReshaper src can be found here.

The Issue

An issue is occurring where the following validation error is being produced when render_pass.draw is called within the TextureReshaper::encode_render_pass method:

UNASSIGNED-CoreValidation-DrawState-DescriptorSetNotUpdated(ERROR / SPEC): msgNum: 0 - VkDescriptorSet 0x32[] bound as set #0 encountered the following validation error at vkCmdDraw() time: Descriptor in binding #0 index 0 requires bound image to have VK_SAMPLE_COUNT_1_BIT but got VK_SAMPLE_COUNT_4_BIT.

It seems that, for some reason, the texture binding in the descriptor set is expected to have a sample count of 1, even though we specify that the SampledTexture is multisampled when creating the bind group layout.


@kvark do you have any thoughts on what I might be doing wrong here? You mentioned yesterday that it should be fine to use a multisampled texture as a shader input, so I'm guessing I must be failing to specify the src sample count in a field somewhere or something along these lines. Or is it possible that the multisampled field of the BindGroupLayoutBinding is accidentally being ignored by wgpu? Let me know if I can provide more info!

Sorry to keep bugging you! This is the last known wgpu related error I'm running into before #452 is ready to land but I'm struggling to crack this one.

@kvark
Copy link

kvark commented Mar 2, 2020

Your shader expects the texture to be non-multisampled:

layout(set = 0, binding = 0) uniform texture2D tex;

The proper type would be texture2DMS.

So from wgpu perspective, the shader doesn't match the pipeline layout (which specifies this binding to be multi-sampled), and we should be erroring out the pipeline creation. This falls under gfx-rs/wgpu#269

@mitchmindtree
Copy link
Member Author

Aaaahhhhhhhhh I see!

TIL texture2DMS is a thing :)

Thank you as usual!

@kvark
Copy link

kvark commented Mar 2, 2020

For the reference, keep this around: https://github.com/KhronosGroup/GLSL/blob/master/extensions/khr/GL_KHR_vulkan_glsl.txt

I think in the future we'll have WGSL specified much better and will be able to recommend it.

mitchmindtree added a commit to mitchmindtree/nannou that referenced this issue Mar 2, 2020
Previously a validation error was occurring due to passing a sampled
texture to the bind group without declaring that the texture was
multisampled in the fragment shader.

This adds some new multisampled shaders that correctly declare the
texture and do the multisampling resolve manually.

Dedicated shaders have been added for common sample counts with unrolled
loops to avoid having the shader deal with conditions based on uniform
data. A fallback shader is provided for all other sample counts.

Closes nannou-org#462.
@mitchmindtree
Copy link
Member Author

Okydoke, just pushed a fix in this commit!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants