-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add support for builtin DComp swapchains #7550
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
base: trunk
Are you sure you want to change the base?
Add support for builtin DComp swapchains #7550
Conversation
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.
Generally looking good, some comments.
will get to this in the next day or two |
…-hunter/wgpu into dev/windows-os-transparent
@cwfitzgerald would you be able to re review when you get time thanks |
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.
Sorry for the delay, looks good in general with a few small comments. I also think that the hardcoded list of blending modes needs to be adjusted based on if DXGI or DComp is selected
Might totally be unfounded and not apply here but DirectComposition on Windows has issues with NVIDIA GPU when used with multiple monitors with different and high(60+) refresh rates. This was seen on Firefox so might be specific to it. |
I definitely wouldn't worry about it here. That issue seems to be Windows 10 specific too. |
Oh! Thank you for doing this, transparency support in wgpu has been a pretty big pain point for me in the past |
Im just traveling abroad atm should be able to get to this in the next week or so |
Boop :) |
So if I understand this correctly, normally one would create and manage a composition (device, target) externally, and pass either the This PR seems to abstract away the most basic form of that, by creating and managing that i.e. maybe this PR should be retitled and have a better description of what it achieves. Technically "dcomp on Windows" is already supported :) |
sorry ended up being very busy. still traveling :). i will be home in about 3 weeks. should have time to work on it then. maybe before but unlikely. if someone else wants to fix it up no worries from me otherwise i will when i get time. |
…ositionCreateDevice2
…ition initialization
i have updated this pr now. i believe i have fixed all comments except for title of pr. |
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.
Sorry for another round of comments, we're almost there!
wgpu-types/src/instance.rs
Outdated
/// Use the DXGI presentation system. | ||
#[default] | ||
Dxgi, | ||
/// Use the DirectComposition presentation system. |
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.
/// Use the DirectComposition presentation system. | |
/// Use a DXGI swapchain made from a DirectComposition visual made from the window. | |
/// | |
/// This supports transparent windows, but does not support fullscreen optimization. |
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.
@cwfitzgerald these user-facing documentation bits need links to upstream documentation exactly how all this works. Perhaps we need to explain that users cannot or should not use this in conjunction with SurfaceTargetUnsafe::CompositionVisual
/SurfaceTargetUnsafe::SurfaceHandle
if they're already managing a layer tree externally (themselves).
Can you backup (link) exactly how this doesn't support "fullscreen optimization" (like borderless fullscreen)? I was under the impression that this uses flip-style present as well which should allow for hardware-compositable/presentable planes in the sawpchain?
EDIT: Or are you saying this because translucent surfaces inevitably require the underlying plane(s) to be rendered and blended (hopefully accelerated in hardware by MPO blending) too? If the user disables alpha blending on the swapchain it should still be able to make this optimization.
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.
Should we also recommend users to set WS_EX_NOREDIRECTIONBITMAP
?
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.
these user-facing documentation bits need links to upstream documentation exactly how all this works. Perhaps we need to explain that users cannot or should not use this in conjunction with SurfaceTargetUnsafe::CompositionVisual/SurfaceTargetUnsafe::SurfaceHandle if they're already managing a layer tree externally (themselves).
I agree, though we can leave this to another PR and spin off an issue from this one, I don't want to hold it up too long as I've already let it sit a while.
Can you backup (link) exactly how this doesn't support "fullscreen optimization" (like borderless fullscreen)? I was under the impression that this uses flip-style present as well which should allow for hardware-compositable/presentable planes in the sawpchain?
I thought I had a conversation about this with Jesse on the d3d12 discord a while ago but I can't find it, so I'll ask again and see what they say.
Should we also recommend users to set WS_EX_NOREDIRECTIONBITMAP?
I honestly don't know.
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.
Re: mpo
I was wrong! Things made from visuals are still eligible for full screen optimization.
Co-authored-by: Connor Fitzgerald <[email protected]>
Co-authored-by: Connor Fitzgerald <[email protected]>
Co-authored-by: Connor Fitzgerald <[email protected]>
Co-authored-by: Connor Fitzgerald <[email protected]>
Co-authored-by: Connor Fitzgerald <[email protected]>
Co-authored-by: Connor Fitzgerald <[email protected]>
@cwfitzgerald done :) |
.as_deref()? | ||
.to_lowercase(); | ||
match value.as_str() { | ||
"dcomp" => Some(Self::DirectComposition), |
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.
Also update the argument name?
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.
oh ya was gonna ask we wanted to update that. though i could see leaving it so its short in the cli
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 having both would be reasonable as well.
profiling::scope!("DirectComposition::DCompositionCreateDevice"); | ||
unsafe { DirectComposition::DCompositionCreateDevice2(None) }.map_err(|err| { | ||
log::error!("DirectComposition::DCompositionCreateDevice failed: {err}"); | ||
crate::SurfaceError::Other("DirectComposition::DCompositionCreateDevice") |
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.
It's surprising that SurfaceError
doesn't have an inner error like InstanceError
.
wgpu-types/src/instance.rs
Outdated
/// Use the DXGI presentation system. | ||
#[default] | ||
Dxgi, | ||
/// Use the DirectComposition presentation system. |
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.
@cwfitzgerald these user-facing documentation bits need links to upstream documentation exactly how all this works. Perhaps we need to explain that users cannot or should not use this in conjunction with SurfaceTargetUnsafe::CompositionVisual
/SurfaceTargetUnsafe::SurfaceHandle
if they're already managing a layer tree externally (themselves).
Can you backup (link) exactly how this doesn't support "fullscreen optimization" (like borderless fullscreen)? I was under the impression that this uses flip-style present as well which should allow for hardware-compositable/presentable planes in the sawpchain?
EDIT: Or are you saying this because translucent surfaces inevitably require the underlying plane(s) to be rendered and blended (hopefully accelerated in hardware by MPO blending) too? If the user disables alpha blending on the swapchain it should still be able to make this optimization.
/// Creates a DirectComposition device and a target for the given window handle. | ||
pub unsafe fn init(hwnd: &HWND) -> Result<Self, crate::SurfaceError> { | ||
let dcomp_device: DirectComposition::IDCompositionDevice = { | ||
profiling::scope!("DirectComposition::DCompositionCreateDevice"); |
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.
Just wondering, is it normal to wrap every external API call - especially these that are well off the hot path - in a profiling scope?
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.
perhaps just a single profile scope for the whole init scope?
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.
Yeah lets do a single scope - generally the decision for what to scope depends on how long it takes, so if there's a single item that takes a long time, scope that, but for processes that only really take a while in aggregate, we can use a single scope.
wgpu-types/src/instance.rs
Outdated
/// Use the DXGI presentation system. | ||
#[default] | ||
Dxgi, | ||
/// Use the DirectComposition presentation system. |
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.
Should we also recommend users to set WS_EX_NOREDIRECTIONBITMAP
?
Could we maybe get an example showing how to use DComp to make window transparency work? Window transparency with wgpu has been a frustration for a while now and having a working example to base things off of would be super helpful imo |
sure i have a testing example i can its basiclly just a triangle with partly clear background |
Co-authored-by: Marijn Suijten <[email protected]>
I think we should, but we can do this as a follow up. |
Connections
#3486
#7108
#5150
Description
add support for builtin DComp swapchains to the dx12 backend.
My main goal for this was to get window transparency to work on windows
Testing
Tested using a basic wgpu app with transparency
Squash or Rebase?
Squash
Checklist
cargo fmt
.taplo format
.cargo clippy --tests
. If applicable, add:--target wasm32-unknown-unknown
cargo xtask test
to run tests.CHANGELOG.md
entry.I dont know if its normal or not but when running
cargo xtask test
i had 201 tests fail withcode 0xc0000005: Invalid access to memory location. (os error 998)
this is run on windows 10