Present via command buffers on Metal #2168
Assignees
Comments
bors bot
added a commit
that referenced
this issue
Jun 23, 2018
2169: Persistent Metal swapchain r=grovesNL a=kvark Includes #2164 Fixes #2168 Fixes #2143 Removes deferred image resolution (yay!), and also renames some of the outdated concepts. We have no flickering, and proper frame sync now. PR checklist: - [x] `make` succeeds (on *nix) - [x] `make reftests` succeeds - [x] tested examples with the following backends: Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, presenting on a queue simply results in
CAMetalDrawable::presentmessage being sent. Apple documentation advises against this approach because the presentation can only wait for operations (it depends on) that have been scheduled. So if we committed a command buffer prior to presentation that hasn't reached the "scheduling" phase, then there is going to be a corruption or some data race for presentation that we definitely do not what to see.The solution would be to have a temporary command buffer created at
submitwhich presents all the things and is getting committed. We can make it a (default) option, but I'm leaning towards just having this as the only true path.The text was updated successfully, but these errors were encountered: