bevy_render: Do not remove VALIDATION_INDIRECT_CALL if Backends contains DX-12#24122
Closed
kfc35 wants to merge 8 commits intobevyengine:mainfrom
Closed
bevy_render: Do not remove VALIDATION_INDIRECT_CALL if Backends contains DX-12#24122kfc35 wants to merge 8 commits intobevyengine:mainfrom
VALIDATION_INDIRECT_CALL if Backends contains DX-12#24122kfc35 wants to merge 8 commits intobevyengine:mainfrom
Conversation
# Objective - Provide a higher quality texture compressor - Automatically generate mipmaps Closes bevyengine#14671. ## Solution - Use the ctt crate ## Testing - New compressed_image_saver example (for now I have merged the textures into this branch, but before merging we should place them in the bevy asset repo) --- ## Showcase <img width="3206" height="1875" alt="image" src="https://github.com/user-attachments/assets/4b236f00-3f5d-4618-a53a-efcc74e9d32b" />
…yengine#24065) # Objective Alternative to bevyengine#24004. bevyengine#23288 adds ltc luts for rect light support which implicitly requires `bevy_image/ktx2` and `bevy_image/zstd` otherwise loading ltc luts will panic. We either accept to always enable area light supoort (bevyengine#24004), or add a feature to opt out it (this PR). ## Solution Gate ltc luts behind a feature and merge them to a texture array. ## Testing `rect_light` example works. --------- Co-authored-by: Kevin Chen <chen.kevin.f@gmail.com>
…f `T` type (bevyengine#24048) # Objective Fixes issue where handles generate no problem regardless of T type via `from_reflect` due to strong handle's being fully opaque and simply cloned. ## Solution Adds a small type id check to the `FromReflect` implemenation which fails conversion if the type id is not what we expect: Reference automatically derived implementation: ```rust impl<A: Asset> bevy_reflect::FromReflect for Handle<A> where Handle<A>: ::core::any::Any + ::core::marker::Send + ::core::marker::Sync, A: bevy_reflect::TypePath, { fn from_reflect(__param0: &dyn bevy_reflect::PartialReflect) -> ::core::option::Option<Self> { if let bevy_reflect::ReflectRef::Enum(__param0) = bevy_reflect::PartialReflect::reflect_ref(__param0) { match bevy_reflect::enums::Enum::variant_name(__param0) { "Strong" => ::core::option::Option::Some(Handle::Strong { 0: { let __0 = __param0.field_at(0usize); let __0 = __0?; <Arc<StrongHandle> as bevy_reflect::FromReflect>::from_reflect(__0)? }, }), "Uuid" => ::core::option::Option::Some(Handle::Uuid { 0: { let __0 = __param0.field_at(0usize); let __0 = __0?; <Uuid as bevy_reflect::FromReflect>::from_reflect(__0)? }, 1: ::core::default::Default::default(), }), name => panic!( "variant with name `{}` does not exist on enum `{}`", name, <Self as bevy_reflect::TypePath>::type_path() ), } } else { ::core::option::Option::None } } } ``` ## Testing added basic tests --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: Greeble <166992735+greeble-dev@users.noreply.github.com>
…e#24089) # Objective - Alongside bevyengine#24086, helps with bevyengine#24084, although I think we should double check any other added conditionals for bind group entries to make sure they are accurate. ## Solution So, originally the `SCREEN_SPACE_TRANSMISSION` was enabled with `key.intersects(MeshPipelineKey::SCREEN_SPACE_SPECULAR_TRANSMISSION_RESERVED_BITS)`. However, a low quality transmission would make this false, since low’s MeshPipelineKey is configured like this: `const SCREEN_SPACE_SPECULAR_TRANSMISSION_LOW = 0 << Self::SCREEN_SPACE_SPECULAR_TRANSMISSION_SHIFT_BITS;`. So, a ScreenSpaceTransmission with Low Quality would break rendering (since another if-block merely checks that the `ScreenSpaceTransmission` component exists) Making it so that the low transmission truly does *not* include the view_transmission_textures makes the transmission render not properly - the spheres disappear! So, I think the proper fix here is to remove the gating around transmission textures. Edit: Another potential fix is to change the condition of the `intersects` but I’m not sure how to encode what we want unless we want to add another bit for `ScreenSpaceTransmission` component exists essentially? Happy to close this PR if that is an acceptable direction. ## Testing `cargo run --example transmission` works for all quality levels.
…evyengine#24046) I was initially using `MessageReader<WindowResized>` in my system for my app but once my system grew to use more and more window events, I refactored to using `MessageReader<WindowEvent>` and matching on its variants. This is where I ran into the issue of the `WindowEvent::WindowResized` case never matching. When making this PR, I noticed `WindowEvent::WindowBackendScaleFactorChanged` and `WindowEvent::WindowScaleFactorChanged` had the same issue. # Objective Fixes bevyengine#15268 ## Solution Instead of writing into `MessageWriter<WindowResized>`, `MessageWriter<WindowBackendScaleFactorChanged>` and `MessageWriter<WindowScaleFactorChanged>`, push into `bevy_window_events` where it gets sent to the `forward_bevy_events` function for syncing the messages. ## Testing I made local modifications to the `window_resizing` example to use a `MessageReader<WindowEvent>` instead of `MessageReader<WindowResized>` like so: ```rs fn on_resize_system( mut text: Single<&mut Text, With<ResolutionText>>, mut resize_reader: MessageReader<WindowEvent>, ) { for e in resize_reader.read() { if let WindowEvent::WindowResized(e) = e { // When resolution is being changed text.0 = format!("{:.1} x {:.1}", e.width, e.height); } } } ``` I ran this example on linux wayland.
# Objective Make the possibility of 1-to-1 `Relationship` clearer in the docs, so that people know it's an option. (There's already a passing mention of it at the top, but that doesn't show that it's supported in code.) ## Solution Added an example to the doc comment to show how it's done, and explained what happens if you try to add another entity anyway. ## Testing Ran `cargo doc` and looked at the new docs to see if they're ok.
… for wgpu (bevyengine#23879)" This reverts commit 60a860d.
kfc35
changed the title
kfc35
added
S-Blocked
Contributor
|
Oh, whoops. So we should have this flag for metal/vulkan. For directx, we need this flag though, as the validation passes actually do additional things... |
Contributor
Author
By “have this flag”, do you mean we should remove the |
kfc35
added
the
S-Waiting-on-Author
Member
|
This PR fixes the issue. If we have different behaviour depending on platform, please add a comment explaining why |
kfc35
changed the title
VALIDATION_INDIRECT_CALL if Backends contains DX-12
kfc35
added
S-Needs-Review
Contributor
Author
|
Ready for review now. Added additional conditions for removing |
kfc35
force-pushed
the
24117_enable_validation_indirect_call_dx_12
branch
from
c50a50c to
56f00c4
Compare
kfc35
added
the
D-Straightforward
Contributor
Author
|
i’ll remake afresh |
pull Bot
pushed a commit
to orzogc/bevy
that referenced
this pull request
May 6, 2026
…ins DX12 (bevyengine#24129) # Objective - Fixes bevyengine#24117 ## Solution - The flag is supposedly necessary for DX12 in wgpu. Add some additional conditions for removing `VALIDATION_INDIRECT_CALL`, and add a comment about it. ## Testing - The revert commit in bevyengine#24122 by itself fixes the issue in Pixel Eagle. It was also confirmed to fix the issue by @meepleek — Thank you for testing locally! - The additional logic has not been verified in Pixel Eagle but it’s simple enough to only need review. (Just decided to remake the PR after main was force pushed)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Objective
Solution
VALIDATION_INDIRECT_CALL, and add a comment about it.Testing