Skip to content

Conversation

JMS55
Copy link
Contributor

@JMS55 JMS55 commented Jun 29, 2025

Objective

Solution

  • Initial implementation of DLSS upscaling, via https://github.com/bevyengine/dlss_wgpu.
  • Future PRs will work more on transparency, exposure, working with custom viewports, fixing inevitable resolution override bugs, etc.
  • DLSS framegen is not planned, but ray-reconstruction is for solari.
  • FSR3/4, XeSS2, and MetalFX temporal upscaling should be easy to add now if a future contributor wants to. In the future we could have an auto-temporal AA component that handles DLSS/FSR/XeSS/MetalFX/TAA fallbacks automatically.

Testing

  • Did you test these changes? If so, how?
    • Run the anti_aliasing example
  • Are there any parts that need more testing?
    • Different types of scene content and rendering effects to make sure they work with DLSS/upscaling
    • Reviewing dlss_wgpu code

Showcase

bafkreib4u2hc7kgru7n6ujh6tjq5aydfcz7m7lfleexvfa6fdixegveaee

@JMS55 JMS55 added the A-Rendering Drawing game state to the screen label Jun 29, 2025
@JMS55 JMS55 added C-Feature A new feature, making something new possible M-Needs-Release-Note Work that should be called out in the blog due to impact M-Deliberate-Rendering-Change An intentional change to how tests and examples are rendered labels Jun 29, 2025
@JMS55 JMS55 added this to the 0.17 milestone Jun 29, 2025
Copy link
Contributor

It looks like your PR has been selected for a highlight in the next release blog post, but you didn't provide a release note.

Please review the instructions for writing release notes, then expand or revise the content in the release notes directory to showcase your changes.

@JMS55
Copy link
Contributor Author

JMS55 commented Jun 29, 2025

@cart not sure what licensing concerns there are with this. See the license notes in https://github.com/JMS55/dlss_wgpu/blob/main/README.md.

Copy link
Contributor

You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.

@JMS55
Copy link
Contributor Author

JMS55 commented Jun 29, 2025

You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.

Lies D:

Copy link
Contributor

You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.

@alice-i-cecile alice-i-cecile added S-Needs-Review Needs reviewer attention (from anyone!) to move forward X-Contentious There are nontrivial implications that should be thought through labels Jun 30, 2025
@cart
Copy link
Member

cart commented Jul 1, 2025

Rad! My only concern here is that we're taking a dependency on an external crate that depends on a specific version of wgpu. This will make upstream bevy wgpu updates harder, as it will require collaboration with owner of the crate (in this case, you, which is much better than a stranger, but still a risk).

@cart not sure what licensing concerns there are with this. See the license notes in https://github.com/JMS55/dlss_wgpu/blob/main/README.md.

I think this is ok, given that the onus is on developers to wire up the SDK themselves.

@JMS55
Copy link
Contributor Author

JMS55 commented Jul 1, 2025

Theoretically it's an optional feature, so it shouldn't block wgpu upgrades. Of course I'm happy to update it asap.

I'm also happy to put it in the bevy repo, up to maintainers. I don't have a preference either way.

Copy link
Contributor

github-actions bot commented Jul 6, 2025

You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.

@alice-i-cecile
Copy link
Member

As part of your reviews, please take a look at (and leave feedback on https://github.com/bevyengine/dlss_wgpu. We need to be confident in (and ideally have multiple people comfortable working with) both this particular PR and the underlying crate.

Copy link
Member

@cart cart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm working on some changes to remove the need to hard code DLSS into bevy_render.

In the interim, please try to answer my open questions :)

#[cfg(any(not(feature = "dlss"), feature = "force_disable_dlss"))]
let instance = Instance::new(&instance_descriptor);

#[cfg(all(feature = "dlss", not(feature = "force_disable_dlss")))]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if a different feature needed to enable DX12 specific instance features? Using Instance::from_hal, at a glance, feels like we're throwing away backend support (or at least, we're throwing away the ability to customize other backends).

Like my previous comment, I don't want to merge until we understand these bounds.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above, you wouldn't ever use the dlss feature on platforms where you didn't intend to support Vulkan.

We could also add DX12 support to dlss_wgpu, but it's just a lot of extra work for no real gain.

@cart
Copy link
Member

cart commented Aug 14, 2025

I've pushed my port to #20565 (which includes those changes). This won't build until bevyengine/dlss_wgpu#8 is merged. The diff will be cleaner when #20565 merges.

github-merge-queue bot pushed a commit that referenced this pull request Aug 15, 2025
# Objective

Currently registering additional required Vulkan features requires
either hard-coding them into `bevy_render` (see the current [DLSS
proposal](#19864)), or forcing
the plugin to take full manual control over wgpu initialization. Neither
is an acceptable or scalable option for a modular engine like Bevy.

## Solution

* Add a new `raw_vulkan_init` Cargo feature, that when enabled switches
to wgpu's raw Vulkan init path, which accepts callbacks that allow
checking and requiring additional Vulkan features.
* Add a new `WgpuRawVulkanInitSettings` resource, which provides wgpu
Vulkan Instance and Device init callbacks, which can be used to detect
and register vulkan features.
* These callbacks can register arbitrary features in the new
`AdditionalVulkanFeatures` resource, which is inserted into the
RenderApp at the same time that the RenderDevice is.

This enables plugins to register initialization callbacks, which must
happen _before_ RenderPlugin. They can then feed off of
`AdditionalVulkanFeatures`, after the renderer is initialized, to detect
if a given feature is supported.

Due to the current lifecycles, this is best accomplished with either:
* A separate "init plugin" that is registered before RenderPlugin, and a
"logic plugin" that does everything else. This should be used if the
plugin logic needs `Plugin::build()` access to render device state,
which needs to be registered _after_ RenderPlugin to have access. The
proposed DLSS feature needs this pattern.
* A single "init plugin" that is registered before RenderPlugin and does
everything. Use this pattern if you can as it is simpler.

With deferred plugin init, we could remove the need for this split.

---------

Co-authored-by: JMS55 <47158642+JMS55@users.noreply.github.com>
github-merge-queue bot pushed a commit that referenced this pull request Aug 15, 2025
# Objective

For example, in:

- #19864 (comment)

The link to the directory containing the release notes is broken.

## Solution

Fix the link.

## Testing

Copy pasted the new link in URL bar.
@JMS55 JMS55 requested review from cart and tychedelia August 15, 2025 14:04
@JMS55 JMS55 added S-Needs-Review Needs reviewer attention (from anyone!) to move forward and removed S-Needs-Design This issue requires design work to think about how it would best be accomplished labels Aug 15, 2025
Copy link
Member

@cart cart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just pushed some changes to adapt to the latest raw_vulkan_init API. I think this is in a good spot to land now. DLSS is a bit more cordoned-off. I think we've landed on the right "middle ground" pattern for proprietary APIs like this:

  1. Separate repo for the bindings to those APIs, with instructions on how to comply with the SDK license requirements.
  2. Bevy-specific logic in the bevy repo, behind an opt-in cargo flag
  3. Do not bake proprietary features into foundational libs (ex: bevy_render, bevy_ecs, etc), even in an opt-in way

@cart cart enabled auto-merge August 15, 2025 20:54
@cart cart added this pull request to the merge queue Aug 15, 2025
Merged via the queue into bevyengine:main with commit 1bb17a9 Aug 15, 2025
36 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Feature A new feature, making something new possible D-Complex Quite challenging from either a design or technical perspective. Ask for help! M-Deliberate-Rendering-Change An intentional change to how tests and examples are rendered M-Needs-Release-Note Work that should be called out in the blog due to impact S-Needs-Review Needs reviewer attention (from anyone!) to move forward X-Contentious There are nontrivial implications that should be thought through
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

NVIDIA DLSS (Deep Learning Super Sampling)
6 participants