-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Update to wgpu 0.18 #10266
Update to wgpu 0.18 #10266
Conversation
Cool, basically LGTM. :) |
wgpu/naga have updated, if you get a chance please check/approve the naga_oil pr and i'll merge and release (unless i need to do something further for the capabilities?) |
Rebased, fixed transmission, and it seems to work now. |
@@ -197,6 +197,10 @@ impl ShaderCache { | |||
} | |||
} | |||
|
|||
// TODO: Check if this is supported, though I'm not sure if bevy works without this feature? | |||
// We can't compile for native at least without it. | |||
capabilities |= Capabilities::CUBE_ARRAY_TEXTURES; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need this for native to compile, and webgl2 still works even with it enabled.
Ideally we feature gate it but I'm not sure how since it's a part of DownLevelFlags
and doesn't seem to be exposed as a wgpu feature or limit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we want to check, we could pass the RenderAdapter
down through PipelineCache::new
and use adapter.get_downlevel_capabilities().flags
. but i think it's ok not to since we already assume support in point shadow bindings anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. Ok. We can fix it if it’s a problem anywhere.
looks like we'll need at least one shader update too: ┌─ crates\bevy_pbr\src\render/utils.wgsl:35:1
│
35 │ ╭ fn octahedral_encode(v: vec3<f32>) -> vec2<f32> {
36 │ │ var n = v / (abs(v.x) + abs(v.y) + abs(v.z));
37 │ │ let octahedral_wrap = (1.0 - abs(n.yx)) * select(vec2(-1.0), vec2(1.0), n.xy > 0.0);
│ │ ^^^^^^^^^^ naga::Expression [26]
38 │ │ let n_xy = select(octahedral_wrap, n.xy, n.z >= 0.0);
39 │ │ return n_xy * 0.5 + 0.5;
│ ╰────────────────────────────^ naga::Function [62]
│
= Expression [26] is invalid
= Operation Greater can't work with [24] and [25] works replacing the |
It works, but it spits out a vulkan validation error when I do that. Also the |
I've seen mentions of the texture binding array bug on 0.12 I think? If so, it shouldn't block this PR as this PR does not cause the regression. What is the vulkan validation error with robtfm's proposal? |
It was an issue on AMD+Linux RADV drivers on 0.12. With wgpu 0.18 (this PR) it's fixed on AMD+Linux RADV, but broken on AMD+Windows (and apparently also broken on AMD+Linux amdvlk). (amdvlk is AMD's official FOSS linux vulkan driver, but people generally use Mesa/RADV because it's better) On Windows at least there's somewhat of a workaround because the issue doesn't happen on dx12.
|
I think we should merge this now and try to investigate / fix after |
There's an upstream patch that fixes the texture_binding_array example on windows+amd+vulkan. I guess since deferred works despite the validation error, it's probably fine? |
this fixes the validation error. seems like it shouldn't be needed but 🤷 diff --git a/crates/bevy_pbr/src/deferred/pbr_deferred_functions.wgsl b/crates/bevy_pbr/src/deferred/pbr_deferred_functions.wgsl
index d401805eb..f888c0f30 100644
--- a/crates/bevy_pbr/src/deferred/pbr_deferred_functions.wgsl
+++ b/crates/bevy_pbr/src/deferred/pbr_deferred_functions.wgsl
@@ -71,7 +71,7 @@ fn pbr_input_from_deferred_gbuffer(frag_coord: vec4<f32>, gbuffer: vec4<u32>) ->
let emissive = rgb9e5::rgb9e5_to_vec3_(gbuffer.g);
if ((pbr.material.flags & STANDARD_MATERIAL_FLAGS_UNLIT_BIT) != 0u) {
pbr.material.base_color = vec4(emissive, 1.0);
- pbr.material.emissive = vec4(vec3(0.0), 1.0);
+ pbr.material.emissive = vec4(0.0, 0.0, 0.0, 1.0);
} else {
pbr.material.base_color = vec4(pow(base_rough.rgb, vec3(2.2)), 1.0);
pbr.material.emissive = vec4(emissive, 1.0); |
@robtfm so one can no longer construct a vecN from components up to vecM, M <= N? |
it seems like some kind of inference issue in the particular case. just below we have |
I’m curious if vec4(vec3(), ) works… |
also doesn't work: |
gfx-rs/wgpu#4695 is the upstream fix. Do we want this backported to avoid breaking downstream user's shaders? Does this actually break anything or is it just a validation error? |
Backported and released in naga 0.14.2, I think this should be ready to be merged assuming CI passes? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
Objective
Keep up to date with wgpu.
Solution
Update the wgpu version.
Currently blocked on naga_oil updating to naga 0.14 and releasing a new version.
3d scenes (or maybe any scene with lighting?) currently don't render anything due to
I'm not sure what should be passed in for
wgpu::InstanceFlags
, or if we want to make the gles3minorversion configurable (might be useful for debugging?)Currently blocked on bevyengine/naga_oil#63, and gfx-rs/wgpu#4569 to be fixed upstream in wgpu first.
Known issues
Amd+windows+vulkan has issues with texture_binding_arrays (see the image here), but that'll be fixed in the next wgpu/naga version, and you can just use dx12 as a workaround for now (Amd+linux mesa+vulkan texture_binding_arrays are fixed though).
Changelog
Updated wgpu to 0.18, naga to 0.14.2, and naga_oil to 0.11.
WgpuSettings.instance_flags
and InstanceFlagsMigration Guide
RenderPassDescriptor
color_attachments
(as well asRenderPassColorAttachment
, andRenderPassDepthStencilAttachment
) now useStoreOp::Store
orStoreOp::Discard
instead of aboolean
to declare whether or not they should be stored.RenderPassDescriptor
now havetimestamp_writes
andocclusion_query_set
fields. These can safely be set toNone
.ComputePassDescriptor
now have atimestamp_writes
field. This can be set toNone
for now.