-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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] - Fix wasm examples #4967
Changes from 5 commits
fa996cc
6a6fa72
325ba84
34e80c5
b1b2090
ddc433f
4fa8d87
014e819
3e5e4ae
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,6 +14,7 @@ keywords = ["bevy"] | |
|
||
[features] | ||
trace = [] | ||
webgl = [] | ||
|
||
[dependencies] | ||
# bevy | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -15,7 +15,10 @@ use bevy_ecs::system::{Res, ResMut}; | |
use bevy_utils::{default, tracing::error, Entry, HashMap, HashSet}; | ||
use std::{hash::Hash, mem, ops::Deref, sync::Arc}; | ||
use thiserror::Error; | ||
use wgpu::{PipelineLayoutDescriptor, ShaderModule, VertexBufferLayout as RawVertexBufferLayout}; | ||
use wgpu::{ | ||
BufferBindingType, PipelineLayoutDescriptor, ShaderModule, | ||
VertexBufferLayout as RawVertexBufferLayout, | ||
}; | ||
|
||
enum PipelineDescriptor { | ||
RenderPipelineDescriptor(Box<RenderPipelineDescriptor>), | ||
|
@@ -117,9 +120,26 @@ impl ShaderCache { | |
let module = match data.processed_shaders.entry(shader_defs.to_vec()) { | ||
Entry::Occupied(entry) => entry.into_mut(), | ||
Entry::Vacant(entry) => { | ||
let mut shader_defs = shader_defs.to_vec(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Curious what @superdump thinks about this one. I think I'm on board for having a suite of "low level feature detection shader defs" that exist everywhere, but this is a big enough change to merit a discussion of its own. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yeah... I fixed a similar issue in #4949 and wanted to try a way that wouldn't need to fix it for other pipelines one by one There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think centralising these kinds of ‘global’ shader defs based on detected features/limits makes a lot of sense. They aren’t different in different renderers or pipelines and they are useful to be able to use without core changes / user code reimplementation, in my opinion. And while specialisation has different roots, the shader cache is centralised. Good idea. This is my initial 0730 after a night out take. :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. best kind of takes! |
||
#[cfg(feature = "webgl")] | ||
shader_defs.push(String::from("NO_ARRAY_TEXTURES_SUPPORT")); | ||
|
||
// TODO: 3 is the value from CLUSTERED_FORWARD_STORAGE_BUFFER_COUNT declared in bevy_pbr | ||
// consider exposing this in shaders in a more generally useful way, such as: | ||
// # if AVAILABLE_STORAGE_BUFFER_BINDINGS == 3 | ||
// /* use storage buffers here */ | ||
// # elif | ||
// /* use uniforms here */ | ||
if !matches!( | ||
render_device.get_supported_read_only_binding_type(3), | ||
BufferBindingType::Storage { .. } | ||
) { | ||
shader_defs.push(String::from("NO_STORAGE_BUFFERS_SUPPORT")); | ||
} | ||
|
||
let processed = self.processor.process( | ||
shader, | ||
shader_defs, | ||
&shader_defs, | ||
&self.shaders, | ||
&self.import_path_shaders, | ||
)?; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,10 +1,8 @@ | ||
//! Renders two cameras to the same window to accomplish "split screen". | ||
|
||
use bevy::{ | ||
core_pipeline::clear_color::ClearColorConfig, | ||
prelude::*, | ||
render::camera::Viewport, | ||
window::{WindowId, WindowResized}, | ||
core_pipeline::clear_color::ClearColorConfig, prelude::*, render::camera::Viewport, | ||
window::WindowResized, | ||
}; | ||
|
||
fn main() { | ||
|
@@ -83,26 +81,25 @@ fn set_camera_viewports( | |
mut resize_events: EventReader<WindowResized>, | ||
mut left_camera: Query<&mut Camera, (With<LeftCamera>, Without<RightCamera>)>, | ||
mut right_camera: Query<&mut Camera, With<RightCamera>>, | ||
mut setup_done: Local<bool>, | ||
) { | ||
// We need to dynamically resize the camera's viewports whenever the window size changes | ||
// so then each camera always takes up half the screen. | ||
// A resize_event is sent when the window is first created, allowing us to reuse this system for initial setup. | ||
for resize_event in resize_events.iter() { | ||
if resize_event.id == WindowId::primary() { | ||
let window = windows.primary(); | ||
let mut left_camera = left_camera.single_mut(); | ||
left_camera.viewport = Some(Viewport { | ||
physical_position: UVec2::new(0, 0), | ||
physical_size: UVec2::new(window.physical_width() / 2, window.physical_height()), | ||
..default() | ||
}); | ||
if resize_events.iter().next().is_some() || !*setup_done { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Alternatively, maybe we should send an initial WindowResized event on platforms that don't do that automatically? That way userspace doesn't need this complexity and we close a "bevy behavior consistency gap"? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can only test on macOS and wasm, where this event isn't sent. For me reading it in that comment was a first discovery 😄 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm now sending the event on window creation. it shouldn't be an issue anyway if there are two events instead of one on some platforms There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I can test those platforms if nobody else beats me to it :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. X11 has a duplicate event now (and it doesn't on main). Gonna try wayland next (both xwayland and native wayland). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. xwayland also has the duplicate event. native wayland is unclear because it crashed on startup for me (the default swap chain format wasnt compatible ... i queried the surface for the preferred format, but even after setting that, the device times out). Nvidia proprietary drivers + wayland are notoriously bad. Windows also now has a duplicate event. (it actually produces 3 resize events on main, one with a higher dpi (2x), and two with the "actual" resolution). With this PR it produces 4 resize events. So its safe to say that xwayland, x11, and windows don't need the extra event. Native wayland is unclear. I think we'll need someone else to test that. But "native wayland" is not the default behavior, and some platforms already produce duplicate events, so I don't think adding a potential duplicate to native wayland is particularly risky. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added a gate for windows and x11, not sure how to gate for xwayland but not native wayland. Anyway as you mention, this kind of event should not be expected to be unique so it should be OK |
||
let window = windows.primary(); | ||
let mut left_camera = left_camera.single_mut(); | ||
left_camera.viewport = Some(Viewport { | ||
physical_position: UVec2::new(0, 0), | ||
physical_size: UVec2::new(window.physical_width() / 2, window.physical_height()), | ||
..default() | ||
}); | ||
|
||
let mut right_camera = right_camera.single_mut(); | ||
right_camera.viewport = Some(Viewport { | ||
physical_position: UVec2::new(window.physical_width() / 2, 0), | ||
physical_size: UVec2::new(window.physical_width() / 2, window.physical_height()), | ||
..default() | ||
}); | ||
} | ||
let mut right_camera = right_camera.single_mut(); | ||
right_camera.viewport = Some(Viewport { | ||
physical_position: UVec2::new(window.physical_width() / 2, 0), | ||
physical_size: UVec2::new(window.physical_width() / 2, window.physical_height()), | ||
..default() | ||
}); | ||
*setup_done = true; | ||
} | ||
} |
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 its worth directly calling out the behavior quirks of WebGL explicitly, to better justify this code to future readers.
On that note, I'm still a little unclear about what the behavior actually is. Is it just "the next renderpass will still have the viewport set, but every pass after that will be fine"?
Should we open a wgpu bug?
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 is what it looks like without that extra render pass
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 tried making the comment more explicit. I don't know if it's a wgpu bug or how WebGL2 works, but I found a lot of people trying to reset viewport when using OpenGL
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.
Gotcha. Its a bit unfortunate because this means users developing things like custom post-processing effects will need to manually hard-code the reset if they want to support wasm viewports. But thats not something we can reasonably fix in this pr.