# Objective
- Clean up our texture format handling.
- Fix#23732
- Get us closer to #22563
- It makes no sense for views to talk about being hdr or not. They have
a texture format, that's it. What does HDR shadows even mean lol
- Same for compositing_space
## Solution
- Remove ExtractedView::hdr
- Add ExtractedView::texture_format
- Move ExtractedView::compositing_space to
ExtractedCamera::compositing_space
- Add texture_format to a bunch of specialization keys instead of hdr
bool
- Convert VolumetricFogPipelineKey to not use flags and just use bool
and texture format
- Remove BevyDefault TextureFormat
- Remove ViewTarget TEXTURE_FORMAT_HDR
## Testing
- Pretty extensively test at this point
This has a migration guide.
---------
Co-authored-by: Willow Black <wmcblack@gmail.com>
Co-authored-by: Máté Homolya <mate.homolya@gmail.com>
Co-authored-by: Luo Zhihao <luo_zhihao@outlook.com>
Co-authored-by: IceSentry <IceSentry@users.noreply.github.com>
# render-graph-as-systems
> [!NOTE]
> Remember to check hide whitespace in diff view options when reviewing
this PR
This PR removes the `RenderGraph` in favor of using systems.
## Motivation
The `RenderGraph` API was originally created when the ECS was
significantly more immature. It was also created with the intention of
supporting an input/output based slot system for managing resources that
has never been used. While resource management is an important potential
use of a render graph, current rendering code doesn't make use of any
patterns relating to it.
Since the ECS has improved, the functionality of `Schedule` has
basically become co-extensive with what the `RenderGraph` API is doing,
i.e. ordering bits of system-like logic relative to one another and
executing them in a big chunk. Additionally, while there's still desire
for more advanced techniques like resource management in the graph, it's
desirable to implement those in ECS terms rather than creating more
`RenderGraph` specific abstraction.
In short, this sets us up to iterate on a more ECS based approach, while
deleting ~3k lines of mostly unused code.
## Implementation
At a high level: We use `Schedule` as our "sub-graph." Rather than
running the graph, we run a schedule. Systems can be ordered relative to
one another.
The render system uses a `RenderGraph` schedule to define the "root" of
the graph. `core_pipeline` adds a `camera_driver` system that runs the
per-camera schedules. This top level schedule provides an extension
point for apps that may want to do custom rendering, or non-camera
rendering.
### `CurrentView` / `ViewQuery`
When running schedules per-camera in the `camera_driver` system, we
insert a `CurrentView` resource that's used to mark the currently
iterating view. We also add a new param `ViewQuery` that internally uses
this resource to execute the query and skip the system if it doesn't
match as a convenience.
### `RenderContext`
The `RenderContext` is now a system param that wraps a `Deferred` for
tracking the state of the current command encoder and queued buffers.
### `SystemBuffer`
We use an system buffer impl to track command encoders in the render
context and rely on apply deferred in order to encode them all.
Currently, this encodes them in series. There are likely opportunities
here to make this more efficient.
## Benchmarks
### Bistro
<img width="1635" height="825" alt="Screenshot 2026-01-15 at 7 57 40 PM"
src="https://github.com/user-attachments/assets/8e55a959-89a3-4947-bfc5-c04780f82e7b"
/>
### Caldera
<img width="1631" height="828" alt="Screenshot 2026-01-15 at 8 13 06 PM"
src="https://github.com/user-attachments/assets/e7e8ae0d-41c3-430f-8b4d-9099b3d922a0"
/>
## Future steps
There are a number of exciting potential changes that could follow here:
- We can explore adding something like a read-only schedule to pick up
some more potential parallelism in graph execution.
- We can use more things like run conditions in order to prevent systems
from running at all in the first place.
- We can explore things like automating resource creation via system
params.
## TODO:
- [x] Make sure 100% of everything still works.
- [x] Benchmark to make sure we don't regress performance
- [x] Re-add docs
---------
Co-authored-by: atlas dostal <rodol@rivalrebels.com>
Upgrade to wgpu 28
> [!important]
> This can't merge until https://github.com/bevyengine/naga_oil/pull/132
does, and the dependency is updated from my fork to the release.
>
> Also requires wgpu 28 in dlss_wgpu:
https://github.com/bevyengine/dlss_wgpu/pull/17
> [!note]
> This does not enable mesh shaders, and neither does the naga_oil PR. I
chose to do an upgrade first, then go back and see about mesh shaders.
Here's a general list of changes and what I did. Commits are grouped by
feature except for the last one, which enabled solari when I ran the
solari example.
## MipmapFilterMode is split from FilterMode
- Split MipmapFilterMode from FilterMode #8314:
https://github.com/gfx-rs/wgpu/pull/8314
solution: implement From for `MipmapFilterMode`/`ImageFilterMode` since
the values are the same. The split was because the spec indicates they
are different types, even though they have the same values.
## Push Constants are now Immediates
- https://github.com/gfx-rs/wgpu/pull/8724
immediate_size is [a
u32](https://docs.rs/wgpu/28.0.0/wgpu/struct.PipelineLayoutDescriptor.html#structfield.immediate_size)
so use that instead of `PushConstantRange`
## Capabilities name changes
- https://github.com/gfx-rs/wgpu/pull/8671
Got new list from
https://github.com/gfx-rs/wgpu/blob/trunk/wgpu-core/src/device/mod.rs#L449
and copied it in.
## subgroup_{min,max}_size moved from Limits to AdapterInfo
- https://github.com/gfx-rs/wgpu/pull/8609
Update the limits to have the fields they have now, mirror the logic
from the other limits calls.
## multiview_mask
- https://github.com/gfx-rs/wgpu/pull/8206
set to None because we don't use it currently. Its vaguely for VR.
## error scope is now a guard
- https://github.com/gfx-rs/wgpu/pull/8685
retain guard and then pop() it later
---
I made one mistake during the PR, thinking set_immediates was going to
be the size of the immediates and not the offset. I'd like reviewers to
take a look at immediates offset and size sites specifically just in
case I missed something.
Here's a bunch of examples running
<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 47
22@2x"
src="https://github.com/user-attachments/assets/83dcf4c8-69f5-480a-b724-86598530f25a"
/>
<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 48
44@2x"
src="https://github.com/user-attachments/assets/46d897fa-1ab2-44ef-8055-fe2fce740dbc"
/>
<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 49
10@2x"
src="https://github.com/user-attachments/assets/6ae7a9bf-0473-4800-8dfc-233a6a41d6df"
/>
<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 49
31@2x"
src="https://github.com/user-attachments/assets/89f84a26-cfbd-4196-bca8-111c3d20ba7b"
/>
## Known Issues
> [!NOTE]
>
> There are no current known issues. Everything previous has been
solved.
- [x] enable extensions can not be written in naga oil in a way that
allows them to be used in composed modules.
Update: this was fixed by introducing a flag in naga-oil to force
shaders to allow ray queries in composed modules when using bevy_solari.
This is temporary and will be different in WESL-future.
<details><summary>old explanation</summary>
This is blocking solari from working on nvidia (solari runs successfully
on macos m1) because it needs `enable wgpu_ray_query;`. Putting the
declaration before `#define_import_path` means it gets stripped out
(afaict), and putting it after results in
```
error: expected global declaration, but found a global directive
┌─ embedded://bevy_solari/scene/raytracing_scene_bindings.wgsl:3:1
│
3 │ enable wgpu_ray_query;
│ ^^^^^^ written after first global declaration
│
= expected global declaration, but found a global directive
```
</details>
- [x] dlss_wgpu mixes apis which [causes panics
now](https://github.com/bevyengine/dlss_wgpu/pull/17#issuecomment-3690847524).
<details><summary>Previous notes as dlss_wgpu was being fixed
here</summary>
The wgpu release notes don't mention which PR this was introduced in,
only saying:
> Using both the wgpu command encoding APIs and
CommandEncoder::as_hal_mut on the same encoder will now result in a
panic.
It was caused by https://github.com/gfx-rs/wgpu/pull/8373 which claimed
to not know of any use cases
> With record on finish, the actual ordering on the command buffer is
deeply counter intuitive (all as_hal would come first) and I think it
additionally was just flat out broken in some ways
> -
https://discord.com/channels/691052431525675048/743663924229963868/1453786307099758683
Possible path forward is using multiple command buffers:
https://discord.com/channels/691052431525675048/743663924229963868/1453795633503670415
</summary>
---------
Co-authored-by: robtfm <50659922+robtfm@users.noreply.github.com>
# Objective
A user was confused about a crash when modifying the
custom_post_processing example.
They added an Hdr feature, Bloom, and were confused about the crash.
The issue is that when using Hdr cameras, the custom_post_processing
pipeline must use Hdr textures.
Fixes#21516
## Solution
Add note about using Hdr textures if Hdr features are enabled.
Note is added to two locations since most users will be looking at the
camera when adding hdr components; not looking at the colortargetstate.
# Objective
- Defer creating `BindGroupLayout` by using a
`BindGroupLayoutDescriptor` and cache the results
- Unblocks `bevy_material` (render-less material definitions)
- Blocked by https://github.com/bevyengine/bevy/pull/21533
## Solution
- Reviewers, look at first commit for mechanism, and following for usage
## Testing
- CI
---------
Co-authored-by: atlas <email@atlasdostal.com>
# Objective
- Some shader examples are much more complicated than others. It can be
confusing for new users that simple example and advanced examples are
next to each other
## Solution
- Introduce a new "shader_advanced" example category
- I'm open to other names, but I named it like that so both folders are
next to each other
## Testing
N/A
## Notes
We should maybe consider a different name than "shader" because some of
them aren't that much about shaders. It could be advanced_rendering or
something like that.
I'm opened to moving more example to this. I just picked the one that
felt the most advanced to me.
I didn't move the compute_game_of_life example because, while it is
complex, the complexity is unavoidable if you want to run a compute
shader right now. I also plan on simplifying it a bit and introduce a
plugin to make it much easier but as it is today I think it's okay to
stay there.
atlv