[Merged by Bors] - Add push contant config to layout

[Neo-Zhixing]

Objective

Allow for creating pipelines that use push constants. To be able to use push constants. Fixes #4825

As of right now, trying to call RenderPass::set_push_constants will trigger the following error:

thread 'main' panicked at 'wgpu error: Validation Error

Caused by:
    In a RenderPass
      note: encoder = `<CommandBuffer-(0, 59, Vulkan)>`
    In a set_push_constant command
    provided push constant is for stage(s) VERTEX | FRAGMENT | VERTEX_FRAGMENT, however the pipeline layout has no push constant range for the stage(s) VERTEX | FRAGMENT | VERTEX_FRAGMENT

Solution

Add a field push_constant_ranges to RenderPipelineDescriptor and ComputePipelineDescriptor.

This PR supersedes #4908 which now contains merge conflicts due to significant changes to bevy_render.

Meanwhile, this PR also made the layout field of RenderPipelineDescriptor and ComputePipelineDescriptor non-optional. If the user do not need to specify the bind group layouts, they can simply supply an empty vector here. No need for it to be optional.

---

Changelog

• Add a field push_constant_ranges to RenderPipelineDescriptor and ComputePipelineDescriptor
• Made the layout field of RenderPipelineDescriptor and ComputePipelineDescriptor non-optional.

Migration Guide

• Add push_constant_ranges: Vec::new() to every RenderPipelineDescriptor and ComputePipelineDescriptor
• Unwrap the optional values on the layout field of RenderPipelineDescriptor and ComputePipelineDescriptor. If the descriptor has no layout, supply an empty vector.

[IceSentry]

LGTM small nit, but not a blocker

Note for reviewers, most of the changes are just adding a new field to existing structs. The actual change is otherwise fairly small.

[IceSentry]

Since there's no Default impl, I would add a comment saying that the expected default value is an empty vec.

[IceSentry]

Actually, wouldn't it be possible to keep the Option for layout and use an Option for push constants too? It would reduce the noise a bit and make it a bit more obvious what to use as a default value.

[Neo-Zhixing]

That's certainly doable, but I would argue that wrapping values in Some(...) is equally noisy. And Vec::new() is a perfectly reasonable value to be used as a default here. The default value for Vec is an empty vector, just like None is the default for Option.

The only field that doesn't already implement Default here is VertexState. Perhaps in the future we can implement From<VertexState> for RenderPipelineDescriptor so you would write

RenderPipelineDescriptor {
    layout: vec![layout1, layout2],
    ...VertexState {
        // Fields for vertex state
    }.into()
}

[IceSentry]

To be clear, by noisy, I meant the current diff is noisy, not the actual usage. I'm fine with no Option personally especially considering that you need to specify a layout anyway most of the time.

Yeah, it would be nice to have a default Impl but for now I'm happy with this.

[kurtkuehnert]

LGTM. I like the move from Option to Vec. It avoids quite a bit of noise when creating pipelines.

We should probably add a default value to our pipeline descriptors.

[bonsairobo]

LGTM % the PreHashMap change.

[IceSentry]

@Neo-Zhixing the CI failure is related to an unused import, I assume because of the PreHashMap change.

[superdump]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-and-install-on-iOS
• build-android
• build (macos-latest)
• build (ubuntu-latest)
• build-wasm
• build (windows-latest)
• build-without-default-features (bevy)
• build-without-default-features (bevy_ecs)
• build-without-default-features (bevy_reflect)
• check-compiles
• check-doc
• check-missing-examples-in-docs
• ci
• markdownlint
• msrv
• run-examples
• run-examples-on-wasm
• run-examples-on-windows-dx12