-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
[Merged by Bors] - enable Webgl2 optimisation in pbr under feature #3291
Conversation
Personally I'd prefer if this was chosen by default for wasm targets, since webgpu is still in beta and IMO it's more important for the common case to "just work". We could revisit this later when webgpu support is rolled out to stable browsers. |
There is already a mostly working webgpu support: https://discord.com/channels/691052431525675048/750833140746158140/915727141130338385 |
WGPU's webgpu backend being mostly complete is irrelevant IMO since webgpu isn't available on any stable browsers. Right now, people will still be only using webgl2 for any releases since that's the only backend that's actually supported by browsers. A potential option here could be to check whether wgpu itself is running on webgpu or webgl2 dynamically though. |
Now it is not possible AFAIR - wgpu uses So I would prefer to rename this feature from |
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.
This mostly looks good to me. I think it's a good idea to get something like this in for now rather than waiting on implementing the wgpu downlevel/feature/limits stuff. My only change is that I think WebGL2 supports array textures, but not cube array textures, so I think the shader def should be changed to reflect that. I would approve otherwise. :)
And as WebGL2 is supported in browsers where WebGPU is behind developer flags still, I think, then it makes sense to make webgl the default as @mrk-its proposed for now. Later when the landscape changes I guess it will make sense to change the default behaviour. What do you think on this one @cart?
@@ -469,6 +475,9 @@ impl SpecializedPipeline for MeshPipeline { | |||
depth_write_enabled = true; | |||
} | |||
|
|||
#[cfg(feature = "webgl2")] | |||
shader_defs.push(String::from("NO_ARRAY_TEXTURES_SUPPORT")); |
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.
I think it is specifically no cube array texture support.
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.
textures of type D2Array
seems to be an issue too, if I don't change them to D2
I don't have shadows for directional lights
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.
Ah, ok. Well then I guess this is fine. :)
I can either add it as a default feature, which means that everyone will have by default only one point light, and the no array textures, or add it as a feature already selected for wasm target, wich means it won't be possible to disable it on wasm. As far as I know there are no way to specify |
actually |
on macOS this works on chrome and firefox but it crashes safari... wgpu examples are working with safari, so maybe an issue on Bevy side Firefox is logging this warning:
and it seems that safari is crashing when calling Could we have a buffer somewhere that should be marked as read and isn't? Chrome is working bug logs
so... yeah Chrome 🎉 After some digging, it seems getBufferSubData is called for the vertex buffer of each mesh |
5758523
to
69c939f
Compare
30a3310
to
25bf2eb
Compare
with the wgpu update, 3D examples fails with a new error on Safari:
Not sure how to fix that 😞 UI and 2D examples work on safari though |
group 0 binding 0 is the View uniform. The mesh pipeline uses the same shader handle for both vertex and fragment stages. The pbr pipeline specialises the mesh pipeline and uses a different shader for the fragment stage. I wonder if the vertex stage shader (mesh.wgsl) containing a fragment entrypoint with the same name (fragment) as the overridden fragment stage shader (pbr.wgsl) that's confusing it somehow...? |
Yup, and somebody did not read the bevy/crates/bevy_pbr/src/render/depth.wgsl Lines 3 to 8 in 3409579
bevy/crates/bevy_pbr/src/render/mesh_view_bind_group.wgsl Lines 1 to 10 in 3409579
but copy pasting to have the same in both didn't fix the issue... |
depth is used for the shadow pass. But I also noted that and I wondered how shadows are even working. Hmm... |
crashes with Safari are due to gfx-rs/naga#1617 |
Co-authored-by: MinerSebas <[email protected]>
Co-Authored-By: Jakob Hellermann <[email protected]>
eaea4aa
to
c28ae4f
Compare
This all looks reasonable to me. I can confirm that this works with the naga fixes: |
Firefox perf is quite bad. But chrome seems smooth (didn't do any actual frametime measurements). |
bors r+ |
# Objective - 3d examples fail to run in webgl2 because of unsupported texture formats or texture too large ## Solution - switch to supported formats if a feature is enabled. I choose a feature instead of a build target to not conflict with a potential webgpu support Very inspired by superdump@6813b2e, and need #3290 to work. I named the feature `webgl2`, but it's only needed if one want to use PBR in webgl2. Examples using only 2D already work. Co-authored-by: François <[email protected]>
Objective
Solution
Very inspired by superdump@6813b2e, and need #3290 to work.
I named the feature
webgl2
, but it's only needed if one want to use PBR in webgl2. Examples using only 2D already work.