You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use this method only in extremely performance-critical applications where the cost of maintaining references to objects is significant, and references by some other part of the application can be guaranteed until the object is no longer needed for command execution.
So one important point is Apple did go this extra step to provide a method, meaning that the performance difference is expected. Since we are manually tracking the lifetimes on other backends, we should be using this code paths on Metal, minus some cases where we currently rely on tracking:
1936: [mtl] manually retain command buffer data r=grovesNL a=kvark
Fixes#1779
PR checklist:
- [x] `make` succeeds (on *nix)
- [x] `make reftests` succeeds
- [x] tested examples with the following backends: Metal
r? @JohnColanduoni@grovesNL
As mentioned on gitter, this doesn't allow us to get rid of the autorelease pools unfortunately. We can see it as a different issue.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
From https://developer.apple.com/documentation/metal/mtlcommandqueue/1508684-makecommandbufferwithunretainedr :
So one important point is Apple did go this extra step to provide a method, meaning that the performance difference is expected. Since we are manually tracking the lifetimes on other backends, we should be using this code paths on Metal, minus some cases where we currently rely on tracking:
The text was updated successfully, but these errors were encountered: