-
Notifications
You must be signed in to change notification settings - Fork 546
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
[mtl] cache depth/stencil states #2195
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.
This looks really good! 👍 I agree it's much easier to follow now.
My only concern would be that the hashmap caching depth stencil states could potentially grow fairly large over time, because we never really release it. But we could improve that in the future.
There seems to be some regression within the CTS, but it doesn't seem related to these commits. I'll look into it.
error!("Using {:?} with no depth attachment!", ds_desc); | ||
ds_desc.depth = pso::DepthTest::Off; | ||
} | ||
pso::DepthTest::On { .. } => {} |
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.
nit: just _ => {}
?
Confirmed the CTS failure seems unrelated to this PR, created #2199 |
Thank you!
With pattern matching, we try to avoid more generic patterns if we know a more specific one.
Bors r=grovesNL
… On Jun 30, 2018, at 02:00, Josh Groves ***@***.***> wrote:
Confirmed the CTS failure seems unrelated to this PR, created #2199
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
2195: [mtl] cache depth/stencil states r=grovesNL a=kvark Fixes the dynamic allocation of depth/stencil states in Metal. PR checklist: - [x] `make` succeeds (on *nix) - [x] `make reftests` succeeds - [x] tested examples with the following backends: metal The new logic goes as follows: - there is a central storage for depth-stencil states in our service pipes - a command buffer keeps a hold of just 2 things: the DS state that came from the last graphics pipeline and the set of stencil masks & reference values - a command buffer then assembles a full DS state from those things in the following sync points: - binding a render pipeline - setting stencil masks - starting a render pass I find this logic easier to understand than the previous solution. It allows us to avoid re-creating Metal depth-stencil states. As a small bonus, it becomes possible to work around Dota's bug of trying to use a depth state without a proper attachment (included in the PR). Co-authored-by: Dzmitry Malyshau <[email protected]>
109: [WIP] Handle sanitation and gfx-hal update r=msiglreith,grovesNL a=kvark Depends on gfx-rs/gfx#2195 Depends on gfx-rs/metal-rs#59 Fixes #103 Co-authored-by: Dzmitry Malyshau <[email protected]>
109: [WIP] Handle sanitation and gfx-hal update r=msiglreith,grovesNL a=kvark Depends on gfx-rs/gfx#2195 Depends on gfx-rs/metal-rs#59 Fixes #103 Co-authored-by: Dzmitry Malyshau <[email protected]>
Fixes the dynamic allocation of depth/stencil states in Metal.
PR checklist:
make
succeeds (on *nix)make reftests
succeedsThe new logic goes as follows:
I find this logic easier to understand than the previous solution. It allows us to avoid re-creating Metal depth-stencil states. As a small bonus, it becomes possible to work around Dota's bug of trying to use a depth state without a proper attachment (included in the PR).