Skip to content
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

Incremental presentation #1397

Closed
kvark opened this issue May 18, 2021 · 2 comments
Closed

Incremental presentation #1397

kvark opened this issue May 18, 2021 · 2 comments
Labels
area: api Issues related to API surface help required We need community help to make this happen. type: enhancement New feature or request

Comments

@kvark
Copy link
Member

kvark commented May 18, 2021

Is your feature request related to a problem? Please describe.
Presenting full screen is wasteful if the user knows only a portion of the screen is changed.

Describe the solution you'd like
A native-only feature that allows the user to specify a rectangle to present.
This isn't a security concern, but a portability one.

Describe alternatives you've considered
No incremental present

Additional context
It's not clear if this is possible, given that the user of a swapchain doesn't know about the number of textures there. So there is no good way for the user to know the baseline, from which the changes were made.

@kvark kvark added type: enhancement New feature or request help required We need community help to make this happen. area: api Issues related to API surface labels May 18, 2021
@cwfitzgerald
Copy link
Member

I highly suspect we will have to expose to the user the amount of images in the swapchain. It also implies letting people render to the swapchain without a clear, something that is currently disallowed.

bors bot added a commit that referenced this issue Jun 1, 2021
1417: Split the tracker into stateful/stateless to reduce the overhead r=cwfitzgerald a=kvark

**Connections**
Implements #1413 (comment)
Reduces the overhead for resource tracking in the Animometer benchmark by up to 50%.

**Description**
We used to use the full tracker set on the usage scopes associated with compute/render passes. A resource tracker has 2 responsibilities: ensuring the resource is held alive, and validating and recording the state transitions. This PR exploits the fact that the latter responsibility is only applicable for buffers and textures. So doing all the lifetime tracking for a pass is a waste: we can instead just attach the lifetimes to the parent command buffer, straight.

In the Animometer benchmark, there is one large buffer, and thousands of bind groups pointing to different offsets into it. The old code would fill up the pass tracker with those bind groups, and then merge it into the command buffer tracker. The new code would just fill up the command buffer tracker instead. Since there is only one buffer, the pass tracking becomes much lighter.

**Testing**
Untested. It would be nice to have some benchmarks here, possibly after #1397 ?

Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
@cwfitzgerald
Copy link
Member

Closing in favor of #2869, this isn't as widespread as it seems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: api Issues related to API surface help required We need community help to make this happen. type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants