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

Panics without explanation when creating render pipeline with >4 fragment color targets #2108

Closed
Keavon opened this issue Oct 23, 2021 · 4 comments
Labels
area: validation Issues related to validation, diagnostics, and error handling help required We need community help to make this happen. type: enhancement New feature or request

Comments

@Keavon
Copy link

Keavon commented Oct 23, 2021

Description
When creating a render pipeline, it is limited to 4 color attachments. This limit is set by MAX_COLOR_TARGETS. WGPU does not provide an error message explaining this, instead it proceeds and another crate (arrayvec) ends up panicking with a very unhelpful error message.

Repro steps
WGPU version 0.11

device.create_render_pipeline(&wgpu::RenderPipelineDescriptor {
		...
		fragment: Some(wgpu::FragmentState {
			...
			targets: // Provide 5 or more `ColorTargetState`s here

In wgpu-hal-0.11.4/src/vulkan/device.rs:1456, the following code tries to call ArrayVec::push() which panics if the array is full (and the array capacity is set to MAX_COLOR_TARGETS):

compatible_rp_key.colors.push(super::ColorAttachmentKey {
    base: super::AttachmentKey::compatible(
        vk_format,
        vk::ImageLayout::COLOR_ATTACHMENT_OPTIMAL,
    ),
    resolve: None,
});

Expected vs observed behavior
A size check against MAX_COLOR_TARGETS should occur and a helpful error message should be provided explaining the maximum of 4, and perhaps offering suggested workarounds.

Platform
Windows

@kvark kvark added area: validation Issues related to validation, diagnostics, and error handling help required We need community help to make this happen. type: enhancement New feature or request labels Oct 24, 2021
@kvark
Copy link
Member

kvark commented Oct 24, 2021

This is a good thing to contribute!

@Anti-Alias
Copy link

Hit this same error myself today.
I was wondering if there was a plan to either increase this value or have it be queryable in WGPU.
I assume it's set to 4 for portability reasons.

Currently trying to implement deferred rendering with 5+ attachments:

  • position (xyz),
  • normal (xyz),
  • diffuse/albedo (rgba),
  • specular (rgb),
  • emissive (rgb)

Not sure if this means I'll need to make multiple passes through the same geometry, or if there's an alternate method that doesn't require me to make 5 attachments.
I considered combining the specular and emissive into one target (emissive(rgb) + specular_intensity(a)), but I want to allow for colored specular highlights.
Still kinda a newbie at WGPU/modern graphics pipelines, so bear with me 😃.

@Keavon
Copy link
Author

Keavon commented Nov 19, 2021

@Anti-Alias if you're in the Rust Gamedev server, check this conversation regarding how to more efficiently use the necessary channels in deferred rendering. I had the same problems before I realized many of those channels are actually unnecessary.

https://discord.com/channels/676678179678715904/676685797524766720/902044811492745216

@teoxoy teoxoy added this to the WebGPU Specification V1 milestone Dec 5, 2022
@jinleili
Copy link
Contributor

This issue was fixed by #2913

@Keavon Keavon closed this as completed Jan 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: validation Issues related to validation, diagnostics, and error handling help required We need community help to make this happen. type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants