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

Scope-based usage tracking in the render pass #443

Closed
kvark opened this issue Jan 8, 2020 · 1 comment
Closed

Scope-based usage tracking in the render pass #443

kvark opened this issue Jan 8, 2020 · 1 comment
Labels
area: performance How fast things go help required We need community help to make this happen. type: enhancement New feature or request

Comments

@kvark
Copy link
Member

kvark commented Jan 8, 2020

Currently, we are creating a new resource tracker for each recorded render pass. It's short-lived and it only accumulates the "current" state of every used resource as a union of all the usages needed by the pass. Once a pass has finished recording, we'll stitch the current state of each resource before the pass with the combined usage of a pass.

It's unfortunate to re-populate a resource tracker from the ground up. I wonder if it would make sense to just extend the number of states stored per resource in the tracker of a command buffer. Currently it's just (initial, current). We could make it (initial, current, temporary). When a pass is started, we'd do something like:

for resource in command_buffer.trackers.resources {
  resource.enter_scope(); 
}
impl Resource {
  fn enter_scope(&mut self) {
    self.temporary = self.current;
    self.current = empty;
  }
}

Then we'd merge all the usage we encounter in a pass (into current) and at the end of the pass do:

for resource in command_buffer.trackers.resources {
  resource.leave_scope(); 
}
impl Resource {
  fn leave_scope(&mut self) {
    if self.current != empty {
      transition(self.temp, self.current);
    }
    self.current = self.temp;
  }
}

The benefit is - having less stuff done for a render pass, so lower overhead.

@kvark kvark added type: enhancement New feature or request help required We need community help to make this happen. area: performance How fast things go labels Jan 8, 2020
kvark pushed a commit to kvark/wgpu that referenced this issue Jun 3, 2021
443: Implement typical Error traits for SwapChainError r=kvark a=DasEtwas

Added Display and Error implementation for SwapChainError, imported Display and Error more nicely for the existing errors.

Co-authored-by: DasEtwas <18222134+DasEtwas@users.noreply.github.com>
@cwfitzgerald
Copy link
Member

Obsoleted by #2662

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: performance How fast things go 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