-
Notifications
You must be signed in to change notification settings - Fork 908
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
Present with damage region (VkPresentRegionKHR) #682
Comments
Thank you for filing! It's great to see a well made issue 👍 I think damage tracking is only feasible if you have full control over your swapchain. I.e. if you rendered to swapchain frame X before, and you render to it again, you know which parts you can rely on being preserved. In WebGPU, every frame is a new frame. So I don't think with the current swapchain model the partial present is an option. An issue on https://github.com/webgpu-native/webgpu-headers would help to kick off the discussion. cc @Kangz |
We'll certainly need more and more presentation extensions. In a way we can do whatever we want for now, as long as the "core" API can be translated to GPUSwapChain, then coalesce APIs later. |
Here, I'm not talking about preserving buffers in the webgpu application, just about the damage hint to the windowing system so the system compositor would preserve parts of the whole monitor output's buffer. Again:
This works just fine with every frame being a new frame, in fact Firefox's legacy GL compositor always renders a full frame and I have added |
@myfreeweb the damage region needs to be specified relative to something. We could accept it relative to the previous frame, an internally accumulate the regions between frames of the swapchain. Is this close to what you are thinking? |
Why would there be a need to accumulate anything? o_0 It already is defined as
https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkPresentRegionKHR.html It's just straightforward data passing, nothing clever is required. |
If I read it correctly, the spec specifically describes what regions of a particular
WebGPU doesn't expose the fact that a swapchain contains multiple images that are recycled. User always gets a new image (from their perspective). So Let's consider this example:
If webgpu-native specifies the dirty rect relative to the previous frame, then the damage regions we pass to the last Vulkan present (internally) would have to include all of A | B | C. |
Nah, you really have to read the
This is a convoluted way of saying "relative to the previous frame". And so, Wayland WSI code in Mesa literally just turns this into for (unsigned i = 0; i < damage->rectangleCount; i++) {
const VkRectLayerKHR *rect = &damage->pRectangles[i];
assert(rect->layer == 0);
wl_surface_damage_buffer(chain->surface,
rect->offset.x, rect->offset.y,
rect->extent.width, rect->extent.height);
} Wayland also doesn't care about VkImages, this is also just "damage since the last frame". |
Ok, that's good to know! I find Vulkan spec wording to be confusing here. |
Note that currently wgpu doesn't allow you to write to a swapchain image without clearing it first, so if things like iced want to take full advantage of it, we would have to allow that somehow. |
@cwfitzgerald yeah, that's kind of an orthogonal issue. "telling the compositor what changed" and "not redrawing stuff on buffers" do not depend on each other, they just use the same data (damage tracking) |
Ah yes, you're right. I somehow thought you had to do one to do the other, 'pologizes |
682: Expose adapter.get_info() everywhere r=grovesNL a=kvark Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
Superceeded by 2869 |
Is your feature request related to a problem? Please describe.
Looks like there is no way to pass the
VkPresentRegion
(and equivalents on other platforms) when presenting a frame.The thing the Vulkan WSI-side code gets as the last arg here:
Describe the solution you'd like
Some way to do that. I can't find anything like that in the WebGPU spec :(
Are custom extensions allowed in wgpu?
Additional context
Damage tracking allows applications to only render changed parts between frames, saving power. In this case, I'm only talking about the compositor-side thing, where applications tell the compositor which regions of the window have changed so the compositor can only update them. This is called
EGL_KHR_swap_buffers_with_damage
in the GL world.The text was updated successfully, but these errors were encountered: